Sectors

Financial, technology, life sciences and the public sector: where the proof must outlive whoever issued it.
Every capability with the label of its state.

Category
ProductSectors
HummandSectors

Hummand enters where a person's act has regulated consequences: a transaction, an authorization to an agent, a consent, a benefit, a grant. What changes per sector is the act type and the source; the receipt is the same.

An act is a request for proof made to a person, like confirming they are alive or that they authorized an operation; a source is where each confirmation comes from; the receipt is the signed record of what happened.

No client name appears here, and no market figure. Other regulated sectors come in through the same act types; every capability carries the label of its state, and what does not exist yet is written, not hidden.

Financial

Description

Fintechs, banks and payment providers: the right person executing the sensitive action, with proof that outlives whoever issued it.

1.0Transaction step-uptarget architecture

A new presence in the middle of a sensitive action: a transfer above a value, a limit change, a new device. The policy can shorten it to level 1 with a passkey when there is a recent positive act.

See the step-up
2.0Registration step-uptarget architecture

Changing critical data, such as e-mail, phone or payment key, only with the person present. Never reuses a previous act.

3.0Dual operatortarget architecture

Two distinct people, each with presence, approving the same operation. Composite receipt, one per operator, linked by the group.

4.0Agent mandateavailable

A human with proven presence authorizes an agent with scope, limits and deadline; every delegated action references the mandate and leaves a receipt.

See Mandate
5.0Onboarding with civil identityin accreditation

Live presence plus the government database, once the source's accreditation arrives. Only the verdict persists; the raw data never leaves.

See Sources

Technology

Description

Platforms, SaaS and marketplaces: a living person behind the account that has consequences, and a human behind every agent that acts on their behalf.

1.0Recurring presence of the accountavailable

An account with consequences, such as one that receives payouts or operates on behalf of others, proves every period that there is a living person, the same as the reference, through a link on the phone. Every proof leaves a receipt chained to the previous one.

See recurring presence
2.0Agent mandateavailable

A human with proven presence authorizes a software agent with actions, limits and validity; every delegated action references the mandate and leaves a receipt. Revocation leaves a receipt too.

See Companies
3.0Delegated actavailable

Level 0, no new human: checks that the mandate exists, is valid, has not been revoked and that the action fits the scope and the limits. Resolves on the spot, with a receipt.

4.0Registration step-uptarget architecture

Changing e-mail, phone or payment key only with the person present, inside the action. Never reuses a previous act. It is not login: it is a new presence in the middle of a sensitive action.

5.0Dual operatortarget architecture

Two distinct people, each with presence, approving the same administrative operation: a release, a bulk deletion, a critical configuration change. Composite receipt, one per operator, linked by the group.

Life sciences

Description

Health operators, clinics and research: the patient, the participant or the professional present at the act the rules require to be recorded, with proof that the committee, the auditor or the regulator verifies without Hummand.

1.0Recurring presence in a programavailable

A study participant or a patient in a long-running program proves presence every period, through a link on the phone, without travelling. Every proof leaves a receipt chained to the previous one.

See recurring presence
2.0Consent with presencetarget architecture

A consent form or a document signed with the person present: the text goes as a hash, the presence is the proof, and the receipt stands as an advanced signature or leans on ICP-Brasil or gov.br.

See Signature
3.0Dual operatortarget architecture

Double check with two distinct people present: dispensing a controlled item, releasing a batch, four-eyes approval. Composite receipt, one per operator.

4.0Person mandateavailable

Legal guardian, curator or representative authorizing on the patient's behalf, with scope, deadline and a document hashed in the receipt. Level 2 since 0.28.0; it rises to level 3 when civil identity is accredited.

5.0Registration with civil identityin accreditation

Live presence plus the government database when registering the patient or the participant, once the source's accreditation arrives. Only the verdict persists; no image stays.

See Sources

Public sector

Description

Pension schemes, public bodies and grants: the living person, again, with a receipt that internal control and the audit court verify without Hummand.

1.0Recurring proof of lifeavailable

Live presence and match with the reference, every period, through a link on the person's phone; every proof leaves a receipt chained to the previous one. It is the policy in production.

See Public sector
2.0Batch campaignsavailable

Many acts of the same type with links and a common deadline, created at once through the API or the dashboard.

See Docs
3.0Granttarget architecture

Applicant present and identified for an administrative act; gov.br account when available.

4.0Person mandateavailable

A human authorizes another with scope, deadline and a document, such as a power of attorney or guardianship, all hashed in the receipt. Level 2 since 0.28.0; it rises to level 3 when civil identity is accredited.

5.0Exception proof by vital statustarget architecture

An on-demand lookup at a death-records source only triggers an exception proof; the proof is still the presence.

See Alerts

In any sector

Description

What does not change: the receipt, consent per step, the integration and what we don't do.

1.0Receipt verifiable without Hummandavailable

Every finished act leaves a signed receipt, chained to the same client's previous one, with hashes only. Any auditor verifies it in the browser or on the command line.

See Receipt
2.0Consent per stepavailable

General before everything, biometric before any capture; versioned texts, recorded in the receipt.

See LGPD
3.0Dashboard and APIavailable

Generate the link with no code, or integrate through the API with the TypeScript client generated from the contract.

See Docs
4.0What we don't do

We are not audit, login or a KYC vendor; we do not compute scores, risk or age; we do not retain image, template or context.

See the boundary
1.0

Verify a receipt

Paste the JSON and the public key. No account, nothing sent: it runs in your browser.

Open the verifier
2.0

Talk to us

A technical conversation, straight with the people who build it, no sales script.

Contact