Designed on the assumption that someone is trying.
A palm cannot be reset like a password. So HathPay keeps as little as it can, encrypts what it keeps, and makes every credential narrow and revocable.
Templates, never images
Captures become a template and are deleted. Templates are encrypted with AES-256-GCM under a key derived for each bank, so one bank's data cannot be read with another's.
Replayed requests fail
Every signed call carries a single-use nonce inside the signature and expires in five minutes. A repeated request is refused and written to the audit log.
Only approved terminals
Terminals sign every request with a private key that never leaves the device. A lost terminal is revoked in one action and stops working at once.
No banking credentials
HathPay never asks for an ATM PIN, card number or online-banking password. Its own PIN is hashed, locks after repeated failures and is asked for only when risk calls for it.
One palm, one customer
A palm already enrolled for another customer is refused. Enrolling both hands closes the route of opening a second account with the other hand.
The customer can stop it
Pause palm payments, lower limits, report a payment or remove HathPay from the bank app. Removal deletes the templates.
What happens to the picture of a hand.
The image exists only long enough to be measured. What is kept is a set of numbers that cannot be turned back into a photograph, encrypted for one bank.
ROI 320 × 3206 orientationsAES-256-GCM · per bankcustomer.removedWhere each protection lives.
| Threat | Control | Where |
|---|---|---|
| A captured request is sent again | Single-use nonce inside the signature; five-minute window; refusal is audited | Every API surface, both directions |
| A stolen or cloned terminal | Per-device P-256 key, operations approval, one-step revocation, per-terminal rate limits | Device trust |
| A payment charged twice | Idempotency keys on every authorisation; reversal when a later step fails | Orchestrator and bank adapter |
| Someone else's palm at the till | 1:N match with a margin to the next-best customer; PIN step-up above a threshold; PIN lockout | Biometric service and risk engine |
| A terminal probing unknown palms | Cooldown after repeated unrecognised palms | Risk engine |
| A record quietly altered | Hash-chained audit log, verifiable from the operations console | Audit ledger |
| One bank reading another's data | Templates encrypted with keys derived per bank; separate stores for templates, operations and payments | Data layer |
What we will prove first.
- Liveness and anti-spoof testing on the NIR terminal, against photographs, screens and replicas.
- Accuracy measured on the pilot population: false accepts and false rejects from real people, not lab samples.
- An independent penetration test and architecture review.
- Hosting onshore or inside the bank's own environment, in line with State Bank of Pakistan outsourcing requirements.
- Keys held in a managed key service or HSM, with rotation.
See it working, end to end, in thirty minutes.
Activation in a bank app, enrolment at a branch terminal and a palm payment settled through a simulated bank. Then the architecture and the pilot plan.