Sectors

Financial, pensions 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, 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-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 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 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

Pensions 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 presence
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 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 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 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 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