Replace SMS OTP without rebuilding your stack

Fyno TOTP can run alongside your existing SMS OTP infrastructure. Most banks introduce it for specific high-risk flows first, such as high-value transfers or card-not-present transactions, while keeping SMS OTP for lower-risk journeys. The Fyno verification layer is independent, so that switching customers over incrementally is an architectural choice, not a technical constraint. You can run both flows in parallel with separate logs for each and migrate cohorts at your own pace.

Your bank controls the re-registration flow. When a customer reports a lost device, your bank server calls Fyno to revoke the existing registration and issue a new token. The customer then re-registers on their new device through the same QR or SDK-based setup they used initially. Fyno does not store any customer credentials on its side: it holds the configuration and token reference, while the device holds the secret. Re-registration is a standard API call from your system to Fyno. One additional case to plan for: if a customer changes their device unlock credentials, the OS permanently invalidates the stored key by design. The SDK surfaces this as a clear error, so that your app can prompt re-registration when it occurs.

Fyno supports SHA-1, SHA-256, and SHA-512 across TOTP tenants. OTP length is configurable from 6 to 9 digits. The validity window is configurable per tenant, typically 30, 45, or 60 seconds. Verification padding can also be set, meaning Fyno can accept a TOTP from the immediately preceding time window to account for slight delays on the customer's side. Each of these parameters is set at the tenant level, so that login and payment tenants can carry different policies.

Building the generation side is the simpler part. What in-house builds typically lack is centralised verification logic, replay protection, multi-tenant policy management, and a full audit log. Fyno provides all of this as a managed layer that your bank server calls for each authentication event. If you have generation handled, you can point your verification calls to Fyno and gain the compliance and audit infrastructure without rebuilding your generation side.

The SDK model gives the bank a first-party experience. Customers see a TOTP display inside the bank's own app, not inside Google or Microsoft Authenticator. Fyno ships native SDKs for both platforms: a Kotlin SDK for Android (API 23+, available via Gradle) and a Swift SDK for iOS (iOS 13+, available via CocoaPods). Both are data-only: they generate TOTPs on the device and expose functions your UI calls. Fyno does not dictate the UX. The TOTP secret is never stored in plain text. On Android, it is encrypted using Android KeyStore with hardware-backed keys where available. On iOS, it is stored in the iOS Keychain. The authenticator model is faster to deploy and requires no SDK integration, but puts the TOTP display inside a third-party app. Both models share the same central verification layer, policies, and audit logs on Fyno.

Fyno blocks the second use of any TOTP. When a code is used successfully, Fyno marks it as consumed. A second verification attempt with the same code returns a failure with a specific reason: reused attempt detected. This is logged alongside the original successful verification, so that your security team can see both events in the audit trail. The protection is enforced centrally, not at the device level, meaning it applies regardless of which integration model the bank uses.

Your bank server makes two types of calls to Fyno: a registration call when a customer enables TOTP, and a verification call for each authentication event. The registration call returns a token and configuration that your app uses to generate the QR code or initialise the SDK. The verification call takes the TOTP the customer entered, the user identifier, and the tenant reference, and returns valid or invalid with a reason. Both are REST API calls. No Fyno component sits inside your core banking system.

Biometrics work well as a local device unlock mechanism, but they are weak for remote verification. A biometric check confirms that the person holding the device passed a local scan. It does not confirm that the device itself is trustworthy, that the transaction being approved is what the user thinks it is, or that the result is cryptographically verifiable by your bank's systems. TOTP gives you a time-bound code that your bank's server independently verifies against a shared secret, producing a deterministic pass or fail that can be logged with transaction context. For regulated authentication flows, observability and auditability matter more than convenience.

RBI has been pushing regulated entities to move beyond sole reliance on SMS OTP for transaction authentication. Fyno TOTP is a direct response to that push: it generates codes on the customer's device, removes telecom and inbox-level risk entirely, and produces a central audit log that documents every verification event. When your internal risk committee or a regulator asks what controls you have in place beyond SMS, Fyno TOTP is a concrete, production-grade answer. Not a roadmap. Not a PoC.