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.
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-up2.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 Mandate5.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 SourcesTechnology
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 presence2.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 Companies3.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 presence2.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 Signature3.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 SourcesPublic 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 sector2.0Batch campaignsavailable
Many acts of the same type with links and a common deadline, created at once through the API or the dashboard.
See Docs3.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 AlertsIn 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 Receipt2.0Consent per stepavailable
General before everything, biometric before any capture; versioned texts, recorded in the receipt.
See LGPD3.0Dashboard and APIavailable
Generate the link with no code, or integrate through the API with the TypeScript client generated from the contract.
See Docs4.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 boundaryVerify a receipt
Paste the JSON and the public key. No account, nothing sent: it runs in your browser.
Open the verifier