How financial institutions in Pakistan meet them with Fortanixor — banks, exchange houses, payment providers, microfinance and fintechs supervised by the State Bank of Pakistan.
Regulation refs: Mobile Applications (Apps) Security Guidelines (2022); Regulations for the Security of Internet Banking; Enterprise Technology Governance & Risk Management Framework (2017); Business Conduct & Fair Treatment of Consumers Regulatory Framework; Customers' Digital Onboarding Framework (2022)
SBP's requirements are circular-based rather than gathered into one framework, and the two that bear on authentication pull in the same direction. The Regulations for the Security of Internet Banking set the floor at Section 2.2.1(b): banks must implement at least two-factor authentication, with the example given as a password for the first factor and a one-time token or dongle for the second. The Mobile Applications Security Guidelines, issued as PSP&OD Circular No. 01 of 2022, then go considerably further for the mobile channel, and they are the more demanding document.
Two clauses in the 2022 guidelines are unusually specific. Section 7.C requires strong customer authentication for initiating mobile payments and for access to sensitive payment and personal data, including multi-factor authentication at registration and a configurable PIN, password, pattern or biometric credential — and adds that authentication must be processed only at the app owner's server end. Section 7.D.iv requires encryption keys to remain in a non-exportable form in a secure key store, and says it may be bound to secure hardware, naming the Trusted Execution Environment and the Secure Element. That is a description of how a FIDO2 passkey already works: the private key is generated inside the secure element, is non-exportable by construction, and is verified server-side.
Two further SBP instruments bear on this page. The Business Conduct & Fair Treatment of Consumers Regulatory Framework restates the mobile-channel authentication requirements almost word for word in its digital-channels section, and adds one control that matters for any voice or contact-centre deployment: institutions shall not require customers to provide OTPs verbally to their officers, including call centre agents, and agents must see card numbers masked to the last four digits. The Customers' Digital Onboarding Framework governs identity proofing at account opening, which is the institution's KYC process rather than ours.
Banks must implement at least two-factor authentication to authenticate customers using internet banking products and services, and must apply additional layered security for high-value transactions. Authentication controls must also account for failed login attempts, session timeouts and re-authentication against predefined criteria.
Regulations for the Security of Internet Banking, Section 2.2.1(b) and 2.2.1(c)
Initiating mobile payments and accessing sensitive payment and personal data must be protected by strong customer authentication, including multi-factor authentication for registration of the app user account and a strong, configurable PIN, password, pattern or biometric credential such as face or fingerprint recognition. A login authentication and a risk-based, financial-value-based transaction authentication must both be in place.
Mobile Apps Security Guidelines, Section 7.C(ii) and 7.C(iii)
Encryption keys must be stored with robust security controls and remain in a non-exportable form in a highly secure, standard key store, which may be bound to secure hardware such as a Trusted Execution Environment or Secure Element. Key use authorisation must be implemented and must not be changed after the keys are generated.
App owners must implement device registration and binding using multiple properties unique to the device, so that only registered devices can reach backend servers, preferably combining hardware, software and service information. Where a user registers multiple devices, they must be notified of every new registration and be able to disable a registered device, and the app owner must keep a record of all of them.
Server-side checks must verify mobile app integrity and detect manipulation. Installation must not be allowed on rooted or jailbroken devices, and apps must not run inside a debugger or emulator, with detection in place for both. Authentication attempts must be logged and monitored to detect login anomalies and possible breaches.
Mobile Apps Security Guidelines, Section 7.G and 7.C(iii)(h)
Apps must log the user off automatically after a configurable idle period, expire all app-specific sensitive data from device memory on logoff or termination, and provide a central procedure to disable access from devices reported lost or stolen. Multiple simultaneous login attempts must be detected and communicated to the user through an alternate channel.
| Requirement | Framework reference | How Fortanixor addresses it | Product |
|---|---|---|---|
| At least two-factor authentication for internet banking customers | Internet Banking Security Regulations, Section 2.2.1(b) | A FIDO2 passkey ceremony is two factors in one gesture: possession of the device holding the private key, and the biometric or PIN that unlocks it. It clears the regulation's own example — password plus one-time token — without either a password to phish or a token to intercept. | FortAuth |
| Strong customer authentication for initiating mobile payments and reaching sensitive data, with MFA at registration | Mobile Apps Guidelines, Section 7.C(iii)(a) and 7.C(iii)(b) | Enrolment binds a passkey to the customer's device under a multi-factor ceremony, and every subsequent payment initiation re-runs it. The PIN or biometric the clause asks for is the same one that unlocks the key in the secure element, so there is no separate credential to manage. | FortAuth |
| Encryption keys non-exportable in a secure key store, bound to a Trusted Execution Environment or Secure Element | Mobile Apps Guidelines, Section 7.D(iv) | This is how a passkey is built rather than something added to it. The private key is generated inside the device secure element, is non-exportable by construction, and its use is authorised by the biometric or PIN at generation time — matching the clause's key-use-authorisation requirement. | FortAuth |
| Authentication processed only at the app owner's server end | Mobile Apps Guidelines, Section 7.C(iii)(g) | The device signs a server-issued challenge and the bank's server verifies the signature against the registered public key. The decision is taken server-side; the app cannot assert a successful authentication on its own. | FortAuth |
| Device registration and binding, with notification of new device registrations and the ability to disable one | Mobile Apps Guidelines, Section 7.B | Each passkey is bound to one device and registered against the customer, giving the bank the per-device record the clause requires and a natural revocation point. Optional device fingerprinting adds the hardware and environment signals the clause suggests combining. | FortAuth |
| Blocking after a configured number of failed authentication attempts, with attempts logged and monitored | Mobile Apps Guidelines, Section 7.C(iii)(e) and 7.C(iii)(h) | Retry limits are enforced by the device secure element, and every ceremony is logged with its result and reason so login anomalies can be detected server-side rather than inferred. | FortAuth |
| Rooted, jailbroken, debugger and emulator environments refused | Mobile Apps Guidelines, Section 7.G(ii) and 7.G(iii) | Optional device fingerprinting and VPN or anonymiser detection feed the app owner's decision to refuse a hostile environment, and Android FLAG_SECURE blocks screen capture during the ceremony. | FortAuth |
| Central disabling of access from devices reported lost or stolen | Mobile Apps Guidelines, Section 7.F(iv) | Revoking the passkey registered to that device ends its access immediately and centrally, without touching the customer's credentials on any other device they have enrolled. | FortAuth |
| Customers must never be asked to read an OTP aloud to a call centre agent | Business Conduct & Fair Treatment Framework, Section 4.3.1(12); 4.3.2(2) and 4.3.2(4) | SBP is explicit: institutions "shall not require the customers to provide OTPs verbally to their officers including the call center agents." A passkey removes the possibility rather than the practice — there is no code for a caller to read out or an agent to hear. FortAgent verifies the caller through FortAuth on their own device before any account action, and the same section's masking rules (agents seeing only the last four digits, data tokenised or masked to anyone rendering assisted banking) are easier to hold when the agent never needs a credential at all. | FortAgentFortAuthFortVoice |
| Risk-based, financial-value-based transaction authentication | Mobile Apps Guidelines, Section 7.C(ii) | FortVoice carries the customer's spoken instruction but never authorises it: anything that moves money triggers a FortAuth passkey step-up scaled to the value of the transaction, so the value-based authentication the clause requires happens on the customer's own device. | FortVoiceFortAuth |
Where a requirement belongs to the bank’s own operations, or where the regulator has published no rule to map to, we say so rather than stretch a row to cover it. This is the boundary of the table above, not a gap in it.
Every clause cited on this page was read in the document below, on the regulator’s own site.
This mapping is provided for guidance and must be validated by the bank's compliance function against the current version of each framework.
Fortanixor's research center is in Pakistan, alongside a local office, so the people who build FortAuth, FortVoice and FortAgent are in the same market and time zone as the institutions running them. All three deploy on-premise, into in-region cloud, or as a hybrid of the two.
Deployment shapes
Runs on
Microsoft AzureGoogle CloudDeployed into your own account and your own region on any of the three, or on-premise where the data must not leave your estate at all.
Live in Pakistan
A FIDO2 passkey ceremony is two factors in one gesture — possession of the device holding the private key, and the biometric or PIN that unlocks it in the secure element — which meets Section 2.2.1(b) of the Internet Banking Security Regulations. On the mobile channel it also answers the more demanding Section 7.C of the 2022 Mobile Apps Security Guidelines, including multi-factor authentication at registration, a configurable biometric credential, and authentication processed at the app owner's server end. The mapping must still be validated by your compliance function against the current version of each circular.
Yes. Fortanixor's research center is in Pakistan, alongside a local office, and all three products deploy on-premise, into in-region cloud, or as a hybrid, so authentication data, speech processing and call records can stay in country. On the regulatory position we can now be definitive: all three SBP instruments behind this page — the Mobile Apps Security Guidelines, the Internet Banking Security Regulations and the Enterprise Technology Governance & Risk Management Framework — have been read, and none contains a data-residency clause. The ETGRM framework in fact contemplates offshore outsourcing. So in-country deployment is a capability we offer, not a requirement we are told to meet.
It can, and SBP does not require you to rush. Unlike Turkey, where BDDK prohibits SMS OTP outright once the mobile app is active, SBP still permits one-time passwords and even names time-based one-time passwords and OTP auto-fetch as acceptable mechanisms in Section 7.C(iii). Banks here typically enrol passkeys alongside the existing OTP, move sign-in first, then the higher-value transactions, and retire the SMS path once enrolment is high enough.
It cites SBP's own circular and section numbering, links to the circular itself, and separates what the product does from what stays with the bank. The downloadable SBP mapping covers Section 7.B through 7.G of the Mobile Apps Security Guidelines and Section 2.2.1 of the Internet Banking Security Regulations, and it names what is outside our scope — including source-code escrow and complaints handling. Anything not traced to a numbered clause is marked rather than smoothed over.
The full control-by-control mapping for FortAuth, FortVoice and FortAgent, as a document your compliance function can review.
