1Executive Summary
The Bank currently operates a Mobile Token (a proprietary soft-token embedded in the Mobile Banking App) as its primary transaction-signing authenticator, and has extended the same Mobile Token to serve as the login method for the Stock Trading App. This report recommends evolving this arrangement onto passkeys (the FIDO2/WebAuthn open standard, using on-device biometrics such as Face ID or fingerprint) as the Bank's next-generation multi-factor authentication foundation.
Two business outcomes are targeted:
- Stock Trading App login modernisation — replace the current "open Mobile Banking App → approve in Mobile Token" login flow with a one-tap biometric sign-in directly inside the Stock Trading App, removing app-switching friction at the moment customers most value speed (market hours).
- Mobile Token infrastructure renewal — rebuild the Mobile Token service on passkey infrastructure, so the same phishing-resistant credential that signs banking transactions also underpins login across the Bank's app portfolio. One shared authenticator, governed once, experienced consistently.
Bottom line: Passkeys are the industry-standard successor to OTP- and approval-based authentication. Regulators (HKMA's "E-Banking Security ABC" measures), platform vendors (Apple, Google, Microsoft) and leading banks are converging on them. Acting now lets the Bank deliver a measurably better login experience, reduce fraud exposure and support burden, and position itself ahead of — rather than chasing — regulatory expectations. A phased 12–18 month programme with co-existence of old and new methods keeps execution risk low.
2Background & Current State
2.1 How authentication works today
| Channel | Current login method | Current transaction authentication |
|---|---|---|
| Mobile Banking App | Username/password + Mobile Token (or biometric unlock of the app, token-backed) | Mobile Token approval / OTP generation for high-risk transactions |
| Stock Trading App | Mobile Token authentication — customer is redirected to (or must open) the Mobile Banking App to approve login | Trade orders confirmed within the trading session; re-authentication via Mobile Token for sensitive actions |
2.2 Pain points of the current model
- Cross-app friction: logging in to trade requires switching between two apps and waiting for an approval prompt. During volatile markets this costs customers time and creates abandoned logins.
- Single point of dependency: if the Mobile Banking App is unavailable, uninstalled, or the device is replaced, the customer cannot access the Stock Trading App at all.
- Approval-fatigue fraud: "tap to approve" prompts are susceptible to social engineering — fraudsters trick customers into approving login attempts they did not initiate ("MFA fatigue / prompt bombing").
- Proprietary lock-in: the Mobile Token is a bespoke solution; its cryptography, lifecycle and recovery flows are maintained entirely in-house, and every new app or channel re-integrates a proprietary SDK rather than an open standard.
- Regulatory trajectory: HKMA is actively steering the industry away from SMS OTP and towards bound-device, in-app, phishing-resistant authentication. A proprietary token will need continual justification; a standards-based passkey aligns by design.
3Why Passkeys — Strategic Rationale
A passkey is a FIDO2 cryptographic credential stored on the customer's device (and optionally synced via the customer's iCloud Keychain or Google account). Authentication is completed with the device's native biometric (Face ID / fingerprint) or device PIN. Unlike passwords, OTPs or approval prompts, a passkey:
Cannot be phished
The private key never leaves the device and only responds to the Bank's genuine domain/app. There is no code to read out to a fraudster and no fake-site replay.
Has no shared secret to steal
The Bank's servers store only public keys. A server breach yields nothing an attacker can use to impersonate customers — unlike OTP seeds or password hashes.
Is one gesture for the customer
Face ID or fingerprint — the same gesture customers already use dozens of times a day. Login completes in roughly 1–2 seconds, inside the app being used.
Is an open, governed standard
Backed by the FIDO Alliance, Apple, Google and Microsoft; natively supported in iOS and Android. No proprietary SDK to maintain; interoperability and vendor support are built in.
Regulatory tailwind: In April 2025 HKMA issued the "E-Banking Security ABC" circular requiring banks to make bound-device, in-app authentication the default for Internet banking logins and high-risk transactions, displacing SMS OTP — with card-issuing banks that moved to bound-device authentication reporting an ~80% drop in related fraud. Passkeys are the natural end-state of this direction: bound to the device, verified in-app, and inherently phishing-resistant. Adopting them positions the Bank ahead of the next regulatory step rather than reacting to it.
4Target Vision: One Authenticator, Two Apps
The strategic goal is a shared passkey authenticator service operated once by the Bank and consumed by both apps:
| Component | Target state (business view) |
|---|---|
| Stock Trading App login | Customer opens the app → Face ID / fingerprint prompt → logged in. No app-switching, no approval prompt. Under the hood this is the Bank-issued passkey, the same credential family used in Mobile Banking. |
| Mobile Token service (re-platformed) | The Mobile Token's transaction-signing and approval functions are re-built on passkey infrastructure. High-risk transactions in Mobile Banking are confirmed with the same biometric gesture, producing a cryptographic, transaction-bound signature instead of a generic "approve" tap. |
| One credential lifecycle | Enrolment, device change, loss/theft recovery, and revocation are governed by one set of policies and one customer journey, regardless of which app the customer starts from. |
| Fallback & continuity | During transition, the existing Mobile Token remains available as fallback. Customers on older devices keep a supported path until migration completes. |
Customers experience it simply: "Your fingerprint / face is now how you sign in and approve — in both apps." The Bank gains a single, standards-based authentication platform to extend to future channels (Internet Banking web login, call-centre verification, branch QR journeys) at marginal cost.
5Customer Experience Improvements
| Journey | Today (Mobile Token) | With passkeys |
|---|---|---|
| Log in to Stock Trading App | Open trading app → switch to Mobile Banking App → approve prompt → return. ~20–40s; fails if token app unavailable. | Open app → Face ID. ~2s, one app, no switching. |
| Approve high-risk banking transaction | Read prompt → tap approve (vulnerable to fatigue attacks); details not cryptographically bound. | Biometric confirmation showing transaction context; signature bound to that specific transaction. |
| New phone / device change | Re-bind Mobile Token: typically branch visit, ATM, or SMS OTP + manual verification. High support volume. | Passkey re-enrolment with strong identity proofing (face recognition or in-branch), aligned with HKMA's 2025 device-binding expectations; synced passkeys restore automatically for many customers. |
| Forgotten credentials | Password + token reset flows; calls to hotline. | Nothing to remember or transcribe. Biometric is the login. |
Expected experience outcomes (consistent with published banking deployments): login success rate ↑ towards 99%+ login time −70–90% login-related support calls −30–50%.
6Security Benefits
- Phishing resistance by design. Passkeys only respond to the Bank's genuine app/domain. The dominant fraud vector in Hong Kong — phishing sites and scam calls harvesting credentials and OTPs — is structurally defeated, not merely mitigated.
- No replayable codes, no prompt bombing. There is no OTP to intercept and no generic "Approve?" prompt to fatigue a customer into accepting. Each authentication is a unique cryptographic challenge.
- Server-side breach containment. Only public keys are stored. A compromise of the authentication database does not yield impersonation material — a materially better position than OTP seed storage.
- Transaction binding. For high-risk transactions, the signed challenge can embed transaction details ("what you see is what you sign"), closing the gap where a fraudster alters payee/amount after approval.
- Biometric data stays on-device. Face/fingerprint data never leaves the customer's phone and is never received or stored by the Bank — an important privacy and liability position under PDPO, and a message that must be front-and-centre in customer communications (see §11).
- Elimination of residual SMS OTP exposure. Where SMS OTP remains as fallback today, the roadmap phases it down in line with HKMA direction, removing SIM-swap and smishing exposure.
7Competitive Positioning
- Industry momentum: Global and regional banks have moved from pilots to mass deployment — e.g. a FIDO Alliance case study of Banesco scaling passkeys to ~2.2 million active users (≈92% of actives) with a 65% decline in identity-theft fraud reports, and a Tier-1 Philippine bank eliminating SMS OTP for 400k+ users while saving ~US$1M/year in SMS costs. Passkeys are now a proven retail-banking pattern, not an experiment.
- Hong Kong field is open: No Hong Kong retail bank has yet made passkeys a headline, cross-app authentication experience. A first-mover position — "one biometric sign-in across banking and trading" — is a credible, marketable differentiator, particularly for the digitally active securities-trading segment where login speed is felt daily.
- Securities clients are a high-value beachhead: Active traders skew towards higher balances, higher engagement, and higher sensitivity to login friction. Winning the trading-login experience first delivers visible value to a segment competitors are courting with zero-commission pricing.
- Platform ecosystem alignment: Apple, Google and Microsoft actively promote passkey UX to consumers; the Bank benefits from that familiarity instead of educating customers on a proprietary mechanism.
8Regulatory & Compliance Considerations (Hong Kong)
| Framework / Authority | Relevance & implications for the programme |
|---|---|
| HKMA — E-Banking Security ABC (Apr 2025 circular) | Requires bound-device, in-app authentication by default for Internet banking login and high-risk transactions, phasing out SMS OTP; also requires face-recognition-grade identity proofing for device binding. Passkeys directly satisfy the "Authenticate in-App" intent and position the Bank for the next round of expectations. |
| HKMA SPM TM-E-1 / OR-2 & cyber resilience expectations | Technology risk management, two-factor authentication for high-risk e-banking transactions, and incident-reporting obligations. The passkey platform must be brought under existing technology-risk governance, with independent security assessment pre-launch. |
| SFC — securities business conduct | The Stock Trading App serves SFC-regulated dealing activities. Login and order-confirmation controls must preserve client identity verification, audit trails, and protection against unauthorised trading. A passkey-bound login with signed order confirmation strengthens the audit trail; the change should be reflected in the licensed corporation's internal controls documentation. |
| PDPO (Personal Data (Privacy) Ordinance) | Biometric templates remain on the customer's device and are not collected by the Bank — a favourable position. The Bank still processes authentication metadata (device, timestamps); PICS/privacy notices and consent wording must be updated, and a Privacy Impact Assessment is recommended. |
| HKMA / HKAB consumer education & fraud mechanisms | Suspicious Account Alert integration, fraud monitoring, and customer-communication obligations continue unchanged; passkey rollout communications should be coordinated with industry anti-fraud messaging (and avoid "we will never ask you to…" ambiguity). |
| Cross-border / group policies | If the Bank is part of a Mainland or international group, align with group cryptographic, data-residency and outsourcing policies early; vendor selection (if any third-party FIDO server/SDK is used) triggers existing outsourcing approval gates. |
Compliance note for an authorised institution: passkey adoption is a change to a critical customer-facing control. Recommend pre-implementation dialogue with HKMA (and internal notification to SFC-facing compliance) under the Bank's normal supervisory-communication practice, plus internal audit and independent security review sign-off before each external rollout phase.
9Implementation Roadmap & Phases
Indicative 15-month programme; sequencing deliberately puts the trading-app login first (highest CX payoff, contained scope) while building the shared platform that the Mobile Token re-platforming then reuses.
Phase 0 · M1–M3
Foundation & Business Case
Vendor/build-vs-buy assessment; solution architecture; HKMA liaison; risk & privacy assessments; budget approval; success-metric baselines.
Phase 1 · M3–M7
Passkey Login — Stock Trading App
Build shared passkey service; staff pilot → closed customer pilot (opt-in) → general availability. Mobile Token login retained as fallback.
Phase 2 · M7–M11
Scale & Default-On
Make passkey the default trading-app login for eligible devices; mass migration campaign; decommission cross-app approval login for migrated users.
Phase 3 · M11–M15
Mobile Token Re-platforming
Rebuild transaction signing on passkey infrastructure in Mobile Banking; transaction-bound signatures for high-risk transactions; phased SMS OTP reduction.
Phase 4 · M15+
Extend & Optimise
Extend shared authenticator to Internet Banking web login and other channels; continuous tuning, legacy method retirement per adoption KPIs.
Stage gates (management checkpoints)
- Gate 1 (end Phase 0): approved architecture, budget, risk assessments, regulator engagement completed.
- Gate 2 (end Phase 1 pilot): pilot KPIs met (login success ≥97%, support ticket rate within threshold, zero critical security findings) before GA.
- Gate 3 (end Phase 2): ≥60% of active trading customers on passkey before default-on hardening.
- Gate 4 (Phase 3): transaction-signing parity proven vs. Mobile Token (security review + parallel-run) before legacy token retirement begins.
10Stakeholder Responsibilities (RACI)
| Workstream | Responsible | Accountable | Consulted | Informed |
|---|---|---|---|---|
| Programme direction & funding | Steering Committee (Digital, Retail, Securities, IT, Risk heads) | CIO / COO | CFO, Business heads | Executive Committee |
| Passkey platform & app integration | IT / Digital Channels delivery teams | Head of IT | Architecture, Security Architecture, vendors | Operations |
| Security, fraud & risk policy | Information Security, Fraud Risk | CISO / CRO | Internal Audit, HKMA liaison | Business units |
| Regulatory engagement & legal | Compliance, Legal | Head of Compliance | HKMA, SFC-facing teams, PDPO/DPO | Steering Committee |
| Customer experience & migration journey | Digital Banking product team; Securities business product team | Head of Retail / Head of Securities | UX research, Customer Service, Branch network | Marketing |
| Communications & adoption campaign | Marketing / Corporate Communications | Head of Marketing | Compliance (wording approval), Fraud Risk (anti-scam messaging) | Frontline staff |
| Frontline readiness & support | Customer Service / Branch Operations | Head of Operations | Product, IT (runbooks, FAQ) | Risk |
11User Migration & Adoption Strategy
11.1 Principles
- Opt-in first, default later, mandate last. Voluntary enrolment with incentives → default offer at natural moments (login, app update) → mandatory only when adoption and fallback metrics justify it. This mirrors successful banking rollouts and respects customer choice.
- Migrate at moments of truth. The best enrolment prompt is at a successful Mobile Token login: "Sign in faster with Face ID next time — set up in 10 seconds." Enrolment completes in-context, inside the app in use.
- Never strand a customer. Every migration wave retains a working fallback (existing Mobile Token during transition; then a controlled recovery path). Device-change and lost-phone journeys are designed before mass rollout and meet HKMA's identity-proofing expectations (face recognition or in-branch).
11.2 Segmentation & waves
| Wave | Segment | Approach |
|---|---|---|
| Wave 1 | Staff + digital-savvy active traders (opt-in) | In-app invitation; early-adopter messaging; intensive feedback loop. |
| Wave 2 | All active Stock Trading App users on passkey-capable devices (iOS 16+ / Android 9+) | Prompt at login; default-on for new customers; marketing campaign. |
| Wave 3 | Mobile Banking base for transaction signing | Prompt at next high-risk transaction approval; branch & hotline assisted enrolment for hesitant segments. |
| Wave 4 | Long-tail: older devices, low-activity accounts | Assisted migration via branch; maintain supported fallback until retirement criteria met. |
11.3 Communication themes
- "Faster" (one touch to trade) and "safer" (cannot be phished) — lead with speed for traders, safety for banking customers.
- Privacy reassurance, said early and plainly: "Your fingerprint and face never leave your phone; the bank never sees or stores them." Published banking cases identify this as the single biggest driver of opt-in resistance — address it proactively.
- Anti-scam framing coordinated with HKMA/HKAB messaging: the Bank will never call to ask customers to approve a login or "verify" a passkey.
12Risk Management
| Risk | Rating | Mitigation |
|---|---|---|
| Low adoption / customer resistance | Medium | Opt-in-first strategy; in-context enrolment; privacy messaging; incentives (e.g. fee waivers for traders); measure weekly and adjust prompts. |
| Device loss / account recovery abuse (social engineering of recovery) | High | Recovery is the new attack surface: enforce face-recognition-grade proofing or in-branch verification per HKMA device-binding expectations; cooling-off periods and alerts on re-enrolment; fraud monitoring on post-recovery transactions. |
| Legacy-device exclusion | Medium | Maintain Mobile Token fallback until retirement criteria; assisted branch migration; device-upgrade offers for vulnerable segments. |
| Platform/vendor dependency (Apple/Google passkey sync behaviours) | Medium | Policy decision on synced vs. device-bound passkeys per use case (device-bound for high-risk signing if required); monitor platform changes; retain Bank-controlled enrolment/attestation policies. |
| Execution/integration risk with core systems | Medium | Phased gates with parallel-run; independent security assessment before each external phase; rollback plan per phase. |
| Regulatory query on control change | Low–Med | Early HKMA engagement; documented control mapping (passkey vs. existing 2FA); audit trail retained end-to-end. |
| Synced-passkey account-sharing edge cases (family iCloud/Google accounts) | Low–Med | Risk-based policy: additional signals + step-up for anomalies; customer education on personal-account hygiene; terms & conditions updated. |
13Cost–Benefit Analysis
13.1 Cost drivers (one-off + run-rate)
- Platform build or vendor licence (FIDO server, app SDKs), integration with both apps, identity-proofing for recovery, security assessments and audits.
- Programme delivery (PMO, UX, testing), migration campaign and frontline training; regulator engagement.
- Parallel-run period operating both Mobile Token and passkey infrastructure.
13.2 Benefit drivers
| Benefit | Basis of estimate |
|---|---|
| Fraud loss reduction | Phishing-resistant authentication removes the leading credential-theft vector. Reference points: bound-device in-app authentication cut related card fraud ~80% in HK (HKMA-cited); banking passkey deployments report large declines in identity-theft fraud reports. |
| SMS OTP cost elimination | A Tier-1 Philippine bank reports ~US$1M/year SMS savings after passkey migration; the Bank's saving scales with its OTP volume and increases further as SMS OTP is phased down in Phase 3. |
| Support & operations savings | Fewer password resets, token re-binds and failed-login calls; published cases show 30–50% reduction in authentication-related contacts and self-service resolution of fraud alerts. |
| Revenue protection & growth (trading) | 2-second login at market open reduces abandoned sessions and failed trades; better trading-app experience supports client retention and acquisition in a fee-competitive brokerage market. |
| Avoided future cost | Retiring a proprietary token stack (and eventually SMS OTP infrastructure) avoids escalating maintenance, cryptographic refresh and compliance-justification costs of a bespoke solution. |
| Brand & regulatory capital | First-mover positioning in HK and demonstrable alignment with HKMA's direction — reputational value that compounds with each subsequent fraud-control circular. |
Indicative view: for a mid-size Hong Kong retail bank, programmes of this type typically reach payback within ~2–3 years on hard savings alone (SMS, support, fraud), with the trading-experience and brand upside on top. A full quantified business case with the Bank's actual OTP volumes, call-centre rates and fraud loss data should be produced in Phase 0.
14Success Metrics (KPIs)
| Dimension | KPI | Illustrative target |
|---|---|---|
| Adoption | % active trading customers enrolled; % of logins via passkey | ≥60% enrolled by end Phase 2; ≥80% of logins passkey-based by Phase 3 |
| Experience | Median login time; login success rate; abandoned-login rate | ≤3s; ≥99%; −50% vs. baseline |
| Security | Credential/phishing-related fraud cases; MFA-fatigue incidents | Material reduction vs. baseline (target ≥50% within 12 months of GA) |
| Operations | Authentication-related support contacts; SMS OTP volume & cost | −30–50% contacts; OTP volume down per phase-down plan |
| Risk & compliance | Recovery-flow abuse attempts detected/stopped; audit findings | Zero critical findings; 100% recovery events monitored with alerting |
| Customer sentiment | App store rating (trading app); post-migration CSAT/NPS | Measurable uplift vs. pre-migration baseline |
15Recommendations & Next Steps
- Endorse the direction: agree in principle to adopt passkeys as the Bank's shared authenticator, with trading-app login as the beachhead and Mobile Token re-platforming as the strategic platform play.
- Commission Phase 0 (next quarter): produce the quantified business case using the Bank's own OTP costs, fraud losses and support volumes; complete build-vs-buy and architecture selection; open supervisory dialogue with HKMA.
- Appoint a joint business–IT programme owner spanning Digital Banking and the Securities business, so the shared authenticator is governed once, not built twice.
- Design the recovery journey first. Identity-proofed re-enrolment (face recognition or branch) is the control on which the entire model's fraud resistance depends — and the flow customers will judge hardest.
- Lock the migration principles (opt-in → default → mandate; fallback until retirement criteria) and the privacy-first communication stance before any code ships.
Decision requested of this committee: (i) endorse the passkey direction and two-phase scope; (ii) approve Phase 0 funding and mandate; (iii) nominate the Steering Committee membership and joint programme owner.
Appendix — Reference Points
- HKMA circular, "New Anti-Digital Fraud Measures: 'E-Banking Security ABC'", 11 April 2025 (B1/15C, B9/29C) — bound-device in-app authentication default; face-recognition-grade device binding; SMS OTP phase-down. Card-issuing banks reported ~80% fraud-rate reduction after moving to bound-device authentication (2024 measure).
- FIDO Alliance case study: Banesco Banco Universal — passkeys scaled to ~2.2M active users (~92% adoption), 12M passwordless transactions/year, 65% decline in identity-theft fraud reports, 7-month phased rollout.
- 1Kosmos case study: Tier-1 Philippine bank — FIDO2 passkeys replacing SMS OTP; 438k+ users, 11M+ transactions, ≥US$1M annual SMS savings.
- FIDO Alliance case study: First Credit Union (NZ) — 58.4% member adoption, 54.5% of authentications via passkeys post-rollout.
- HKMA SPM TM-E-1 (Technology Risk Management) and OR-2 (Operational Resilience); SFC internal control guidelines for licensed corporations; Personal Data (Privacy) Ordinance (Cap. 486).
Disclaimer: this report is prepared for internal management discussion. Quantified benefits marked as reference points derive from cited third-party deployments and should be re-based on the Bank's own data in Phase 0 before investment approval.