Layer 01 securedBook a demoLayer 01 securedBook a demoLayer 01 — Authentication · ekShield
Replace SMS OTP with phishing-resistant, device-bound authentication across every channel — mobile, web, call centre, ATM, and 3DS. Compliant with CBUAE, RBI, SAMA, BSP, and MAS mandates. White-labelled and live at UAE's 3rd largest bank.
Ektar Bank · locked
09:41
Push · signed challenge delivered
Transfer request
AED 42,500.00
Biometric check
Matching device-bound passkey…
Authentication · ekShield
Transfer approved
ECDSA P-256 · sig 3f9a·c2e1
01
Device-bound, phishing-resistant credentials
02
One system across mobile, web, call centre, ATM, and 3DS
03
Compliant with CBUAE, RBI, SAMA, BSP, and MAS
The secret behind every one-time code is created on Ektar's servers, delivered once during registration, and stored only after every check passes. It belongs to one customer, on one device, for one bank — and it is never written down in readable form anywhere on the phone.
| What we protect | How it is protected |
|---|---|
| The one-time code secret | Held inside the phone's dedicated security chip, encrypted, and marked so it cannot sync to the cloud, be backed up, or be restored onto another device. On Android the code is calculated inside the chip itself, so the secret is never handed to the app at all. |
| Registration details and PIN | Encrypted at rest with bank-grade AES-256 encryption, using a key that also lives in hardware. The PIN is stored one-way wherever it does not need to be recovered. |
| Biometric approval | Bound to the customer's current fingerprint or face enrolment. If a new biometric is added or the set changes, the binding is invalidated and the customer must re-authenticate. |
| What it takes to unlock | Two independent factors together: something only that specific handset holds, and something only the customer knows — their device passcode. Biometric approval adds a third. None of the key material can be exported, copied, or read by software. |
| Data in transit | Encrypted in transit as standard, with optional end-to-end encryption on top. Secrets and PINs never appear in API responses or logs. |
Full technical whitepaper — including platform flows, enforcement points and risk assessment — available under NDA.
PIN policy
Rejected before it is accepted
The PIN must match its confirmation, meet the bank's required length, be numeric, and avoid sequences or three or more repeated digits. Old PINs cannot be reused.
Retry & lockout
Per-registration retry counter
Each failed verification decrements the counter; when retries are exhausted the PIN state locks and further attempts are blocked. A successful verification resets it.
Session gating
Local auth, with a reuse window
Biometric availability is checked when the app starts, changes to the customer's biometrics end the trusted state, and once the bank's reuse window expires the customer authenticates again.
ekShield checks that the customer's phone has a passcode or lock screen set, and requires one before registration completes. Ektar recommends enforcing this in production: without a device lock, protection falls back to possession of the handset alone, which no longer meets strong customer authentication or card-industry expectations.
| Dimension | Hardware-backed | PIN-only |
|---|---|---|
| Physical security | Secrets isolated in the phone's security chip | No hardware barrier — 80% weaker |
| Attack resistance | Keys cannot be copied off the device | Secrets reachable by software — 80% weaker |
| Authentication assurance | Hardware proof that the customer was present | The app's word for it — 60% weaker |
| Key protection | Bound to the handset, non-exportable | Exportable if the PIN is known — 60% weaker |
| Compliance readiness | Meets strong-authentication and card-industry expectations | Complete loss |
Across the GCC, South Asia, and Southeast Asia, regulators have banned SMS OTP, mandated passkeys, and required real-time malware detection. Every bank in these markets needs what Ektar builds — and many have a hard deadline to decide.
UAE — CBUAE Notice 3057. SMS OTP and email OTP banned. In-app verification, passkeys, and biometrics mandated.
Saudi Arabia — SAMA Counter-Fraud Framework. FIDO2 device-bound credentials mandated. Penalties up to SAR 5M per breach.
India — RBI Authentication Directions 2025. Sole reliance on SMS OTP banned for high-risk transactions.
Singapore — MAS/ABS Directive. SMS OTP phased out for all retail bank digital token users.
Philippines — BSP Circular 1213. Direct prohibition on SMS/email OTP for high-risk banking transactions.
Malaysia — BNM RMiT 2026. Device binding and risk-based authentication mandated for all licensed banks.