Public sector
A benefit paid without an up-to-date proof of life is value at risk.
The proof on the phone, and the value at risk of each cycle in front of the agency.
Every benefit paid to someone who has not done the proof of life is value at risk: an unreported death becomes an undue payment until the next proof. Each Hummand cycle closes with two values from the agency itself: covered, for those who proved, and at risk, for those who have not yet. The proof goes to the beneficiary's phone, with no queue and no travel, which weigh most on the elderly, and each one leaves a signed receipt.
Proof of life is the periodic confirmation that the beneficiary is alive. Value at risk is the sum of what the agency pays to those who have not yet proved in the cycle, computed from the value it provides, not estimated. The receipt is the signed record of each proof, which internal control and the audit court check on their own.
No client name appears here, and no market figure. Every capability carries the label of its state: available, in accreditation or target architecture; what does not exist yet is written down, not hidden.
How it works
Description
Four steps, from the list of beneficiaries to the receipt, from the dashboard and with no integration.
1.0The campaignavailable
The agency pastes the list of beneficiaries from its spreadsheet, by the reference it already uses, such as the registration number, and sets a common deadline. Up to 500 proofs at once; the links come out in a CSV, to go through the channel the agency already has with the beneficiary.
For periodic proof of life, a reverification cycle opens each round by itself, in the birthday month or on a date, and closes with how many proved it and the value covered and at risk, summed from the value the agency reports.
See the Dashboard2.0The proof on the phoneavailable
The beneficiary opens the link on their own phone, reads what the proof is for, consents and answers a live presence challenge on the screen. In the browser, with no app to install and no trip to an office.
The photo on record can be attached to each proof after creation, in the campaign too; with it, presence comes with the comparison.
See recurring presence3.0A receipt for each proofavailable
Every finished proof leaves a signed receipt, chained to the previous one from the same agency: what happened, when and at what assurance level, with no image and none of the beneficiary's data in the clear.
See Receipt4.0Deadlines and pending proofsavailable
The dashboard shows each campaign's progress, the proofs about to expire and those that expired without renewal. What to do with each pending case is the agency's decision; Hummand delivers the proof, it does not suspend benefits.
See AlertsWhat about gov.br?
Description
The gov.br proof of life costs the agency nothing, and it is worth using. Hummand covers where it does not reach and delivers what oversight checks on its own.
1.0Who is left outavailable
The gov.br proof requires the gov.br app and biometrics on file with the driving licence or the electoral court. Whoever has neither is left out of it and goes back to re-registration.
With Hummand, the link opens in the phone's browser, with no app, and the comparison is against the enrolment photo the agency itself attaches.
See recurring presence2.0A receipt for oversightavailable
Each Hummand proof leaves a signed, chained receipt that internal control and the audit court check with the public key, without asking Hummand for anything. The cycle closes in the agency's dashboard with the value covered and the value at risk.
See Receipt3.0The two togethertarget architecture
The gov.br account as a plugged source, next to presence. gov.br says the identity was validated at some point; Hummand proves the person is present now. They add up; neither replaces the other.
See SourcesFor oversight
Description
What internal control and the audit court receive: a proof they check on their own, without asking Hummand for anything and without having to trust it.
1.0The batch as it was signedavailable
The receipts leave the dashboard exactly as they were signed. The auditor checks signature and chain in the browser or on the command line, with the published public key, without access to Hummand's systems.
Open the verifier2.0The chain points to the gapavailable
A receipt removed or altered in the middle of the series shows in the verification. A missing proof does not stay invisible: the chain exposes it.
3.0The team's trailavailable
Who opened the evidence of a proof, when and with what declared reason; and what the team did in the dashboard, with filters by period, person and type, and CSV export.
4.0The dossier for the audit courtavailable
The agency generates a link with a deadline to the dossier of a proof, with the recipient and the purpose declared. The audit court or internal control opens it without an account, and each opening becomes a signed receipt the agency sees in its dashboard. The link can be revoked at any time.
Personal data
Description
No image of the face is kept after the proof, the receipt carries only hashes, and the agency remains the data controller; Hummand is the processor.
1.0Nothing kept of the faceavailable
Image and template are discarded after the proof; what stays is the result and the hash of the reference. The beneficiary's reference is keyed with a secret of the agency, never in the clear.
See LGPD2.0Erasure on requestavailable
By proof or by the reference the agency itself assigned, by key destruction, with a record of who erased and when.
3.0National residency by agreement
By contractual agreement, the operation can be entirely national: server, database, backups, keys and live presence itself. Today's installation is described, without omission, in Security.
See SecurityWhat comes next
Description
What is in the code or in the plan for the public sector, each item with the label of its state.
1.0Civil identityin accreditation
Live presence plus the government database, when the source accreditation arrives. Only the verdict persists; the raw data never leaves.
See Sources2.0Time stampin accreditation
The date of each receipt attested by an ICP-Brasil Time Stamp Authority, a third party that is not Hummand. Ready in the code; it goes live with the authority contract.
See Capabilities3.0Exception proof on a death noticetarget architecture
A death notice from a vital records source, such as SISOBI or the national civil registry, only triggers an exception proof; the proof is still the presence.
See Sources4.0Attorney and guardianavailable
Someone who cannot take the proof alone authorizes another person, 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.
How to contract
Description
By contract, for companies and for government: scope, volume of acts, assurance level and data residency defined in the conversation. In the public sector, through the instruments of public procurement.
1.0How we charge
Per completed act, approved or rejected, with a minimum allowance in the annual contract and a lower price per act as volume grows. An act that expires or is cancelled without a result is not charged. The amount is set in the contract.
2.0Request a demo
By e-mail, with the agency, the scheme, the approximate number of beneficiaries and how often the proof is due. The answer comes from the people who build the platform.
Request a demo3.0For the process
Security, LGPD, capabilities and what Hummand does not do are published, with the label of each item's state, for the terms of reference and the agency's review. The technical sheet sums up security and LGPD in two pages.
Download the technical sheet (PDF)4.0The sheet to take along
This page on one A4 sheet, for the process and for whoever decides.
Download the sheet (PDF)Verify a receipt
Paste the JSON and the public key. No account, nothing sent: it runs in your browser.
Open the verifier