Every password-based login has the same structural flaw: the thing that proves who you are can be copied. It can be phished, reused across sites, leaked in someone else's breach, or simply guessed. Adding an SMS code on top mitigates the symptom without addressing the cause.
AnyBanqID is our digital identity product, and it starts from a different premise — the credential should be something that cannot be transmitted at all.
How device-bound keys work
When someone enrols, their phone generates a private key inside its secure hardware — the Secure Enclave on iOS, the hardware-backed keystore on Android. The private key never leaves that chip. Only the public half is registered with the service.
To log in, the service sends a challenge; the phone signs it, gated by the user's biometric; the service checks the signature. There is no shared secret in transit, nothing on the server worth stealing, and a phishing site has nothing useful to capture.
You cannot phish a signature the user's fingerprint authorised and the hardware refused to export.
Approving actions, not just logging in
The same mechanism signs specific actions, not only sessions. A high-value transfer can require a fresh biometric-gated signature over the exact transaction details, so approval is bound to what was actually shown on screen rather than to a session token acquired earlier.
Standards, not a walled garden
- OpenID Connect, so existing applications integrate the way they already know how
- FIDO2/WebAuthn principles for the credential model
- A developer portal for keys, clients and testing
- Sinhala, Tamil and English throughout — an identity product nobody can read is not an identity product
Losing your phone
The obvious objection to hardware-bound credentials is device loss. Recovery runs through re-verified identity rather than a security question: the user proves who they are again, and a new key is enrolled on the new device while the old one is revoked. It is slower than a password reset link, and that is the point — account recovery is the route attackers take when the front door is solid.
Why SMS OTP is not the answer either
The usual upgrade from passwords is a code by SMS. It genuinely helps against credential stuffing, and it is far better than nothing. But it is a shared secret with a delivery problem: it can be intercepted, socially engineered out of the user, or redirected through a SIM swap. It also costs money per message and fails exactly when the network is congested.
We still use OTP where it is the right tool — confirming a debit against a saved bank account, for instance, where the bank relationship is what matters. We just don't use it as the front door.
What the server actually stores
- A public key — useless to an attacker who steals the database
- A device identifier and enrolment date
- An audit record of authentications and approvals
- No password hash, no shared secret, nothing that can be replayed elsewhere
The security value of this is not subtle. A breach of the credential store yields nothing an attacker can authenticate with — which is a fundamentally different position from leaking password hashes and hoping the work factor holds long enough.
Sinhala, Tamil and English are not a feature
A national identity product that only works for people comfortable reading English excludes most of the country. Localisation is not a checkbox near the end of the project; it constrains layout, string handling and error messages from the first screen. We build it in from the start because retrofitting three scripts into a finished interface never goes well.
For the teams integrating it
From an application's perspective this is ordinary OpenID Connect. You redirect, the user authenticates on their device, you receive tokens. The hardware-bound key, the biometric prompt and the challenge exchange all happen below the layer you integrate with — which is the point. Security that requires every integrating team to understand it will eventually be integrated wrongly.
Where it fits
AnyBanqID handles authentication. VerifiaOS establishes identity in the first place and keeps the compliance record. AnyBanq uses both to turn an application into something a bank can process. Each works on its own, and together they cover the full path from a stranger to a verified customer.
