How financial institutions in Saudi Arabia meet them with Fortanixor — banks, exchange houses, payment providers, microfinance and fintechs supervised by the Saudi Central Bank.
Regulation refs: SAMA Cyber Security Framework v1.0 (2017); SAMA Rules on Outsourcing (2019)
SAMA's Cyber Security Framework is control-numbered and prescriptive, and it applies well beyond banks — the circular that issued it covers the banking sector, the finance sector, payment systems and payment service providers, credit bureaus and the regulatory sandbox. For customer-facing authentication the operative control is Section 3.3.13, Electronic Banking Services, which requires multi-factor authentication at registration and across every customer electronic banking service, and again at the moments that carry the loss: sign-on, adding or modifying a beneficiary, utility and government payments, high-risk transactions above limit, and password reset. Section 3.3.5 is a separate control governing workforce and privileged access; it is not the customer control, and a mapping that cites it for customer sign-in cites the wrong clause.
SMS one-time passcodes are not prohibited by the Framework, but they sit awkwardly inside it: Section 3.3.13 requires MFA to be requested and activated through different channels, restricts mobile-number changes to a branch or ATM, and requires notification to both the old and new number when a number changes — a set of controls written around the SIM-swap and interception risks that one-time codes carry. A FIDO2 passkey removes the code altogether: the private key stays in the device secure element, is unlocked by biometric or PIN, and is bound to the bank's origin, so a spoofed site has nothing to collect and nothing to replay. On residency, Section 3.4.3 is explicit — cloud services should in principle be located in Saudi Arabia, and using them outside the Kingdom requires SAMA's explicit approval.
Every customer electronic banking service must be behind multi-factor authentication, starting at registration. SAMA names the specific events that require it again: sign-on, adding or modifying beneficiaries, utility and government payments, high-risk transactions over limit, and password reset.
Cyber Security Framework Section 3.3.13, control consideration 4(b)
Authentication mechanisms must be requested and activated through a different channel from the one they protect, beneficiaries must be added and activated through different channels, tokens must be password protected, and the account must lock after three incorrect passwords or PINs.
Cyber Security Framework Section 3.3.13, control consideration 4(b)
The electronic banking standard must cover online, mobile and phone banking: distribution through official application stores, detection and removal of malicious apps and lookalike sites, sandboxing, non-caching, and communications built to defeat man-in-the-middle attacks.
Cyber Security Framework Section 3.3.13, control consideration 4(b)
Applications must be built under an approved secure system development life cycle, with secure coding standards, a documented authorisation matrix, data protection aligned to the classification scheme covering privacy of customer data, and vulnerability and patch management.
Cyber Security Framework Section 3.3.6, control considerations 4 and 5
In principle only cloud services located in Saudi Arabia should be used; using cloud outside the Kingdom requires explicit SAMA approval, as does adopting a cloud service at all. The provider may not use the data for secondary purposes, data must be logically segregated, and on exit it must be returned or irreversibly deleted.
Cyber Security Framework Section 3.4.3, control consideration 4(a) and 4(b)
Security logs must be collected, processed, reviewed and retained, with sufficient detail, for a minimum of one year. Defined categories of cyber security incident must be reported to SAMA immediately.
Cyber Security Framework Section 3.3.14 (retention); Section 3.3.15 (incident reporting)
| Requirement | Framework reference | How Fortanixor addresses it | Product |
|---|---|---|---|
| Multi-factor authentication for all customer electronic banking services, from registration onward | CSF Section 3.3.13, control consideration 4(b) | FortAuth replaces the password-plus-OTP pair with a single FIDO2 passkey ceremony that is itself two factors: possession of the device holding the private key, and the biometric or PIN that unlocks it. The same credential covers mobile app, web, cardless ATM and 3-D Secure. | FortAuth |
| Step-up authentication at sign-on, beneficiary changes, utility and government payments, high-risk transactions and password reset | CSF Section 3.3.13, control consideration 4(b) | Each of these events triggers a fresh passkey ceremony rather than a re-used session. The event log records which of them prompted the challenge, so the control can be evidenced per transaction type rather than asserted. | FortAuth |
| Authentication that cannot be collected by a lookalike site or replayed | CSF Section 3.3.13, control consideration 4(b) — man-in-the-middle prevention | Passkey credentials are bound to the bank's origin. A phishing domain cannot complete the ceremony because the browser will not release a credential scoped to another origin, and there is no code in transit for an interceptor to capture. | FortAuth |
| Account lockout after three incorrect passwords or PINs | CSF Section 3.3.13, control consideration 4(b) | PIN and biometric retry limits are enforced by the device secure element, which locks the credential after repeated failure. FortAuth additionally records each failed ceremony with its reason. | FortAuth |
| Mobile and online channel hardening: official app stores, anti-tampering, no caching of sensitive data | CSF Section 3.3.13, control consideration 4(b) | Optional device fingerprinting, VPN and anonymiser detection, and Android FLAG_SECURE to block screen capture. No authentication secret is cached, because the private key never leaves the secure element and never transits the network. | FortAuth |
| Secure development life cycle and secure coding for customer-facing applications | CSF Section 3.3.6, control considerations 4 and 5 | FortAuth ships as SDKs and a REST API built under a documented SDLC, so the bank integrates a maintained authentication component rather than writing credential handling into its own app. | FortAuth |
| Cloud services located in Saudi Arabia unless SAMA explicitly approves otherwise | CSF Section 3.4.3, control consideration 4(b) | All three products deploy on-premise, in in-region cloud, or hybrid. An on-premise or in-Kingdom deployment keeps the residency question inside the bank's existing approval, rather than creating a new cross-border cloud arrangement to seek approval for. | FortAuthFortVoiceFortAgent |
| Speech and call content handled without leaving the approved region | CSF Section 3.4.3, control consideration 4(b) | FortVoice processes speech in the bank's own region, and any money-moving instruction it understands is authorised by a FortAuth passkey step-up before it executes — the voice carries the instruction, it does not authorise it. | FortVoiceFortAuth |
| Security logs retained with sufficient detail for at least one year | CSF Section 3.3.14 | Every authentication ceremony is logged with its result and reason, and every FortAgent call is transcribed, scored and summarised with a full audit trail, exportable into the bank's existing retention. | FortAuthFortAgent |
| SAMA approval before launching a new customer-facing service | CSF Section 3.3.13, control consideration 4(b) | FortAgent's policy controls, allow-listed tools, AI disclosure to callers and human handoff give the bank a documented description of what the automated channel may and may not do — which is what a new-service submission has to describe. | FortAgent |
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.
Deployable inside the Kingdom, which keeps Section 3.4.3's data-location expectation satisfied without an application to SAMA for cross-border cloud use.
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.
A FIDO2 passkey ceremony is two independent factors in one gesture: possession of the device that holds the private key, and the biometric or PIN that unlocks it in the secure element. That meets the multi-factor requirement in Section 3.3.13 control consideration 4(b), which requires MFA at registration and across every customer electronic banking service. Because the credential is origin-bound and no code is transmitted, it also answers the man-in-the-middle prevention the same control asks for. The mapping must still be validated by your compliance function against the current version of the Framework.
Yes, and Section 3.4.3 effectively expects it: in principle only cloud services located in Saudi Arabia should be used, and using cloud outside the Kingdom requires explicit SAMA approval. FortAuth, FortVoice and FortAgent all deploy on-premise, in in-region cloud, or hybrid, so authentication data, speech processing and call records can stay inside the Kingdom. FortVoice processes speech in the bank's own region rather than shipping audio to a global endpoint.
It can, and most rollouts get there in phases rather than at once. SAMA does not ban SMS OTP, but Section 3.3.13 wraps it in controls written around its weaknesses — channel separation, branch-or-ATM-only mobile number changes, and alerts to both the old and new number. Banks typically enrol passkeys alongside the existing OTP, move sign-on first, then the step-up events Section 3.3.13 names, and retire the SMS path once enrolment is high enough. The passkey and the OTP can run side by side during that period.
It reads control by control, in SAMA's own numbering, and it distinguishes what the product does from what remains with the bank. The downloadable SAMA mapping lists each requirement with its Framework reference, how FortAuth, FortVoice or FortAgent addresses it, and — just as importantly — the requirements that are outside our scope, such as mobile-number-change controls that sit with your channel operations. Entries we have not been able to pin to a numbered clause are marked rather than smoothed over.
The full control-by-control mapping for FortAuth, FortVoice and FortAgent, as a document your compliance function can review.
