Wallet Security: Device Binding, PIN, Biometrics and Tokenization

Device binding ties a wallet to a specific phone, so that the wallet cannot simply be opened on a different device with a stolen password. When the customer first registers, the system records a device fingerprint made from the device identifier, the SIM details and the app installation identifier, and stores it against the customer profile. If the customer logs in from a new device, the system must trigger a step up check, such as an OTP to the registered mobile number plus a confirmation of the device change. A BA should specify what happens when a customer changes phones, loses a phone, or has two devices, and should require that a device change never silently transfers a wallet without an explicit customer confirmation and a risk check. The wallet PIN is the everyday gatekeeper, and its design must balance convenience with protection against guessing. A typical wallet PIN is four or six digits, it is never stored in plain text, and it is verified against a hashed value held in a secure server, not on the phone itself. After three to five wrong attempts the wallet should lock temporarily, and after repeated failures it should require an OTP reset or a full re-authentication. The BA must also specify that the PIN entry screen never shows the digits, never allows screenshots in the PIN flow where the platform supports it, and never sends the PIN in a log file. A common audit finding is a PIN that can be bypassed by reinstalling the app, so the requirement must state that the PIN is tied to the customer profile on the server, not to the local app data. Biometrics add a convenient second layer, but they must be designed as a shortcut to the PIN rather than as a replacement for server side authentication. When a customer enables fingerprint or face recognition, the phone verifies the biometric locally and then releases a secure token that the app sends to the server to authorise the transaction. The biometric template never leaves the phone, and the server must be able to revoke the biometric binding if the customer disables it or changes devices. A BA should document the fallback when biometrics fail, for example after three failed attempts the app must ask for the PIN, and should state that a high value transaction always requires the PIN even if biometrics are enabled. This prevents a single biometric bypass from emptying a wallet. Tokenization protects card details when a wallet is funded by a card or when a wallet issues a card token for payments. Instead of storing the real sixteen digit card number, the system stores a token that is useless outside the specific wallet and merchant combination, and the real card number is held only by the token service provider such as the card network. If a fraudster steals the token from a merchant database, they cannot use it to shop elsewhere, and the token can be revoked instantly without reissuing the physical card. A BA working on a card funded wallet must specify the token lifecycle, issuance, suspension, deletion on card expiry, and re-tokenization when a card is replaced. The requirements should also state that no full card number, CVV or PIN is ever stored in the wallet database. Fraud controls run quietly in the background and are often the difference between a wallet that survives a fraud attack and one that makes the news. A modern wallet risk engine checks velocity, such as ten loads of 9,999 rupees in one hour, device and location anomalies, such as a login from a new city minutes after a transaction in another city, and behavioural patterns, such as a first ever payment to a new merchant for the full wallet balance. When a rule fires, the system can step up the authentication, hold the transaction for review, or block it outright and notify the customer. The BA must document each rule, its threshold, its action and its customer message, and must require that every blocked transaction is logged with the rule that fired, so that the fraud team can tune the rules without guessing.