How financial institutions in Qatar meet them with Fortanixor — banks, exchange houses, payment providers, microfinance and fintechs supervised by the Qatar Central Bank.
Regulation refs: QCB Technology Risks Regulation for Banks (2018); QCB Technology Risk Instructions for Financial Service Operators (2022); QCB Information and Cyber Security Regulation for PSPs (2022)
QCB's Technology Risks regulation is a single long, numbered instrument covering governance, operations, enterprise security, business continuity and fraud, and it draws openly on Qatar's National Information Assurance Policy and the NIST cyber security framework. It reads much like SAMA's Cyber Security Framework in structure, which is why banks operating across both markets can usually run one control set — but Qatar is more specific in one important place.
Section 10.10.3 requires two-factor authentication for transaction-signing, to authorise internet and online banking transactions. That is a step beyond authenticating the person at sign-in: the regulation asks for the transaction itself to be signed. Section 10.3.5 separately requires internet banking to carry a separate transaction password, two-factor authentication, a multi-channel process for registering payees, an upper limit on transaction value and SMS alerts. A FIDO2 passkey is a signing credential rather than a shared secret, and with Secure Payment Confirmation the amount and payee are carried into the signature itself, which is the closest available answer to what 10.10.3 asks for.
Two further 2022 instruments sit alongside the banks regulation rather than replacing it, and they widen this page beyond banks. The Technology Risk Instructions apply to Financial Service Operators — exchange houses, investment companies, finance houses and their brokers — and the Information and Cyber Security Regulation applies to Payment Service Providers. Both carry a residency rule the banks regulation does not: the encryption mechanism must be under the institution's full control, including the key management system, with private keys generated and stored outside the cloud, on-premises in Qatar. Both were checked for language superseding the 2018 banks regulation and contain none, so for banks that document still governs.
The bank must implement two-factor authentication for transaction-signing, to authorise internet and online banking transactions. This is stated separately from authenticating the customer at sign-in, and applies to the authorisation of the transaction itself.
Internet banking systems must carry a separate transaction password, two-factor authentication, a multi-channel process for registering payees, an upper limit on transaction value, and SMS alerts to customers. Access controls must ensure only employees who need particular information can reach it and validate transactions.
The bank must evaluate the security requirements of its internet systems and adopt encryption algorithms of well-established international standards, subjected to rigorous scrutiny by the international cryptographic community or approved by authoritative professional bodies or government agencies.
System access must be managed through an appropriate authentication mechanism, and based on sensitivity the system owner must implement multi-factor authentication. Authentication data in use must be protected against replay, man-in-the-middle and session hijacking. Two-factor authentication is required for remote access to critical systems.
Technology Risks Regulation, Section 8.10.2.7, 8.10.2.9 and 8.10.5.2
The bank must establish and operate a Security Operations Centre functioning 24x7, on site or in Qatar, for centralised and coordinated monitoring of cyber risks and management of security incidents. Logs must be protected against modification or deletion, with access restricted and integrity monitored continuously.
For banks, all hosting of applications and data — whether in the institution's own data centre or at an application service provider — must be physically located within the State of Qatar. For Financial Service Operators and Payment Service Providers, the encryption mechanism must additionally be under the institution's full control, including the key management system, with private keys generated and stored outside the cloud environment, on-premises in Qatar. Sensitive data must not sit in a non-controlled cloud; a private cloud under the institution's control is the stated alternative.
| Requirement | Framework reference | How Fortanixor addresses it | Product |
|---|---|---|---|
| Two-factor authentication for transaction-signing on internet and online banking | Section 10.10.3 | FortAuth signs rather than authenticates-then-trusts. Each authorisation produces a cryptographic signature from a private key held in the customer's device secure element, and with Secure Payment Confirmation the amount and payee are bound into the signed data, so the signature is specific to that transaction rather than to the session. | FortAuth |
| Two-factor authentication for internet banking customers | Section 10.3.5 | A passkey ceremony is two factors in one gesture: possession of the device holding the key, and the biometric or PIN that unlocks it. It replaces the separate transaction password the same clause contemplates, without a second secret for the customer to remember or an attacker to phish. | FortAuth |
| Authentication data protected against replay, man-in-the-middle and session hijacking | Section 8.10.2.9 | Credentials are bound to the bank's origin and the private key never leaves the device, so there is no authentication secret in transit to replay or intercept, and a lookalike domain cannot complete the ceremony at all. | FortAuth |
| Encryption algorithms of well-established international standard, scrutinised by the international community | Section 10.10.2 | FIDO2 and WebAuthn are open public-key standards published by the FIDO Alliance and the W3C and implemented in every major browser and mobile platform. Fortanixor's implementation is FIDO2 certified against the published specification, which is an independent test of conformance rather than a self-assertion. | FortAuth |
| 3-D Secure for cardholder authentication, and step-up scaled to the sensitivity of the action | Technology Risks Regulation 10.11.5 and 8.10.2.7 | Section 10.11.5 requires 3-D Secure at a minimum from all card issuers for cardholder authentication. One FortAuth passkey credential covers 3-D Secure alongside the mobile app, web and cardless ATM, so the cardholder authenticates the same way everywhere rather than meeting a separate scheme flow, and the same credential can be required at graduated points so the check follows the sensitivity of the action. | FortAuth |
| Logs protected against modification or deletion, with integrity monitored | Section 8.4.4 | 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 own protected log store rather than held only in the product. | FortAuthFortAgent |
| All hosting of applications and data physically located in Qatar, with keys under the institution's control | Technology Risks Regulation 9.10.2.2; FSO Instructions 1.8.8; PSP Regulation 6.8 | All three products deploy on-premise or into in-region cloud, so the applications and their data sit physically in Qatar as Section 9.10.2.2 requires, and the key management can stay under the institution's own control. A passkey helps structurally as well: the customer's private key is generated in their own device secure element and never leaves it, so the most sensitive key in the flow is not hosted anywhere at all. | FortAuthFortVoiceFortAgent |
| Service providers implement controls at least as stringent as the bank's own | Section 9.10.1.16 | An on-premise or in-region deployment keeps the control boundary inside the bank's own estate, so the bank's existing controls apply directly rather than being mirrored contractually by a third party holding the data. | FortAuthFortVoiceFortAgent |
| Speech and call content processed without leaving the approved region | Section 9.10.1.15 | 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 |
| Caller identity established before an automated channel takes an account action | Section 10.3.6 — only those who need the information can reach it and validate transactions | FortAgent verifies the caller through FortAuth on their own device before any account action, with allow-listed tools bounding what the automated channel can do and human handoff available at any point. | FortAgentFortAuth |
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.
Served from our Gulf and Pakistan offices with in-region deployment: on-premise, in-region cloud, or hybrid.
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 provides 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 10.3.5 for internet banking. Qatar goes further than most of the region in Section 10.10.3, which requires two-factor authentication for transaction-signing rather than only for sign-in, and a passkey answers that directly because each authorisation produces a signature rather than a session token. The mapping must still be validated by your compliance function against the current version of the regulation.
You must. Section 9.10.2.2 of the Technology Risks Regulation requires banks to ensure that all hosting of applications and data — in their own data centre or at an application service provider — is physically located within the State of Qatar, and Section 8.4.5 puts the Security Operations Centre on site or in Qatar. For Financial Service Operators and Payment Service Providers the 2022 instruments add that the key management system must be under the institution's full control with private keys generated and stored outside the cloud, on-premises in Qatar. All three products deploy on-premise or in in-region cloud, and a passkey keeps the customer's own private key in their device rather than in anyone's data centre.
For banks, it can — QCB's 2018 Technology Risks Regulation does not ban one-time codes, so banks typically enrol passkeys alongside the existing OTP, move sign-in first, then transaction-signing under Section 10.10.3, and retire the SMS path once enrolment is high. For Payment Service Providers the answer is no, and we should be straight about it: Section 23.6 of the 2022 PSP regulation requires a payment OTP as one of the factors when authenticating the customer, and recommends combining it with a PIN, password or secure biometrics. In that scope a passkey is the stronger second factor, not a replacement for the OTP. Which regime applies to you depends on your licence, so confirm it with your compliance function.
It cites QCB's own section numbering, links to the regulation itself, and separates what the product does from what stays with the bank. The downloadable QCB mapping covers Sections 8.4, 8.10, 9.10 and 10.3 through 10.12, and it names what is outside our scope — transaction value limits, the SOC itself, payment card authentication — so the table is not read as claiming more than it does.
The full control-by-control mapping for FortAuth, FortVoice and FortAgent, as a document your compliance function can review.
