Sectors
Financial, pensions 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, a benefit, a grant, a signature. What changes per sector is the act type and the source; the receipt is the same.
No client name appears here, and no market figure. Every capability carries the label of its state; 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 mandatetarget architecture
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 SourcesPensions and 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 recurring presence2.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 mandatetarget architecture
A human authorizes another with scope, deadline and a document, such as a power of attorney or guardianship, all hashed in the receipt. Responds as not executable today, by nature.
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 anti-fraud, 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