Skip to main content
Central Bank of Kuwait

CBK authentication and app-security requirements.

How financial institutions in Kuwait meet them with Fortanixor — banks, exchange houses, payment providers, microfinance and fintechs supervised by the Central Bank of Kuwait.

Regulation refs: Cyber and Operational Resilience Framework (CORF) v1.0 (December 2025); Instructions for Regulating the Electronic Payment of Funds (Resolution No. 45/471 of 2023); Circulars for Regulating the Electronic Payment of Funds, incl. Circular No. 2/BS, IBS/534/2023; Bank Customer Protection Manual (Circular No. 2/BS/IBS/349/2015)

Kuwait is the market where the regulator names the standard. Clause 8.3.1.3 of the Cyber Resilience Baselines in CBK's December 2025 Cyber and Operational Resilience Framework requires strong multi-factor authentication to secure access, and out-of-band verification to authorise critical actions — account activation, fund transfers, bill payments and beneficiary addition — using one of three methods: an OTP from a third-party authenticator app, an in-app push approved by biometric or PIN, or device-based authorisation, for example FIDO2, tied to a registered mobile device. SMS OTP, which appeared in the equivalent list in CBK's 2020 Cybersecurity Baselines, is not one of the three. Clause 8.1.2.5 names FIDO2 again for multi-factor authentication at digital onboarding, and clause 8.3.1.2 cuts OTP validity to a maximum of two minutes.

That does not mean SMS has gone from Kuwaiti banking. Circular No. 2/BS, IBS/534/2023 still requires an OTP SMS when a customer adds a beneficiary, a 12-hour wait before the beneficiary is activated, and a call through the bank's official phone service whenever the customer's registered device is not recognised. The same circular asks banks to build security systems that generate codes inside their mobile apps so that no transaction can be made from any other device, which is what a device-held passkey signature does. The framework reaches the contact centre too: clause 8.1.3.4 bars generic or easily obtained verification questions, and 8.1.3.5 requires MFA before sensitive details change through the IVR. On AI it is specific: clause 7.1.1.2 requires CBK approval at least one month before an emerging technology goes live, and 7.1.2.4 requires AI models to be explainable and auditable.

What Central Bank of Kuwait requires

01 / 06

Strong MFA for access and critical actions, with FIDO2 named

Regulated entities must implement strong multi-factor authentication to secure access, and out-of-band verification to authorise critical actions such as account activation, fund transfers, bill payments and beneficiary addition. The permitted methods are an OTP generated by a third-party authenticator app, an in-app push notification approved by biometric or PIN, or device-based authorisation (e.g. FIDO2) tied to a registered mobile device. OTPs are valid for two minutes at most, and multi-factor authentication including methods such as FIDO2 must also be used during digital onboarding.

CORF, Chapter 4 Cyber Resilience Baselines, clauses 8.3.1.2, 8.3.1.3 and 8.1.2.5

02 / 06

Authenticated, registered and limited customer devices

The mobile app must verify the customer's mobile number and authenticate the device on first use. Access is limited to up to three validated devices, or up to six where strong authentication, device attestation and continuous monitoring are in place. Customers must be able to deactivate registered devices remotely, and biometric login must be offered where the device supports it.

CORF, Chapter 4 Cyber Resilience Baselines, clauses 8.3.1.9, 8.3.1.10, 8.3.1.12 and 8.3.1.13

03 / 06

Bank measures against electronic fraud

When a beneficiary is added through internet or mobile banking, an OTP SMS must be sent, the customer must be notified, and the beneficiary must not be activated for at least 12 hours unless the customer confirms. If the customer's registered device or SIM is not recognised, the bank must call the customer through its official phone service to verify before processing any transaction. Banks must also build security systems that generate codes inside their mobile apps, so that no transaction can be made through any other device.

Circular No. (2/BS, IBS/534/2023), items 1 and 3

04 / 06

Contact-centre and IVR verification that cannot be researched

Identity checks used by customer service centres must not be generic, easy to obtain or repeated. CBK gives balances, recent transactions and personal questions as examples of weak checks, and registered mobile plus a secure PIN, or voice biometrics, as examples of acceptable ones. Changes to sensitive customer information through ATMs, mobile apps, IVR or online banking may be made only after the customer is authenticated with MFA.

CORF, Chapter 4 Cyber Resilience Baselines, clauses 8.1.3.4 and 8.1.3.5

05 / 06

AI adoption approved by CBK, explainable and auditable

Adopting an emerging technology such as AI or machine learning needs CBK approval, requested at least one month before go-live with the risk assessment attached. Customers must be made aware of the emerging technologies used in the products they are offered. Data used for training and inference must be protected under applicable privacy rules, and AI models must be explainable and auditable where they drive high-impact decisions, and monitored for drift, reliability and traceability.

CORF, Chapter 4 Cyber Resilience Baselines, clauses 7.1.1.2, 7.1.1.7 and 7.1.2.3 to 7.1.2.5

06 / 06

Customer confidentiality that extends to third parties

Banks must protect customers' financial and personal information and provide secure systems for electronic transactions. That duty covers data held by a third party that supports the bank, and the bank stays responsible for what outsourced entities do. E-payment and e-money providers carry the same responsibility for data held by their outsourced third parties, and need CBK's prior written approval before using a cloud provider for their payment activity.

Bank Customer Protection Manual, Principles Six and Nine and Section Eighth, item 2; E-Payment Instructions, Articles 28, 29 and 30

Control mapping

How Fortanixor maps to CBK requirements.
RequirementFramework referenceHow Fortanixor addresses itProduct
Device-based authorisation (e.g. FIDO2) tied to a registered mobile device, for access and critical actionsCORF Chapter 4, clause 8.3.1.3(c); also 8.1.2.5FortAuth is a FIDO2 implementation, which is the example the clause names. The private key is created in the secure element of the customer's registered phone and cannot be exported, and the biometric or PIN that unlocks it is a second factor in the same gesture. The same ceremony binds the credential at digital onboarding, which is where clause 8.1.2.5 asks for FIDO2-grade MFA.FortAuth
Out-of-band authorisation of fund transfers, bill payments and beneficiary addition, with the customer verifying the amountCORF Chapter 4, clause 8.3.1.3; Circular No. (2/BS, IBS, PS/547/2024), item 2With Secure Payment Confirmation, the amount and payee are shown on the device and bound into the signed data, so the record proves what the customer approved, not just that a code was sent. Circular 547/2024 describes an OTP message carrying the amount. Whether a signed confirmation can stand in for that message on payment links is for the bank to confirm with CBK.FortAuth
Device authentication on first use, a limited number of validated devices, and remote deactivationCORF Chapter 4, clauses 8.3.1.9, 8.3.1.10 and 8.3.1.12Each registered device holds its own passkey, so the bank's list of credentials is its list of validated devices. It can cap them at three or six, revoke any one remotely, and notify the customer of every registration and removal. Optional device fingerprinting adds the device signals that 8.3.1.9 lists.FortAuth
Security codes generated inside the mobile app so that no transaction is made from another device, and checks on unrecognised devicesCircular No. (2/BS, IBS/534/2023), items 1 and 3A passkey signature can only be produced by the device that holds the key. Every transaction approved this way is therefore evidence that it came from the registered device, which is the outcome item 3 asks for. Optional device fingerprinting and VPN or anonymiser detection flag the unrecognised device or out-of-country VPN that item 1 describes, so the bank's verification step runs before the transaction does.FortAuth
Contacting the customer through the bank's official phone service when a device is not recognisedCircular No. (2/BS, IBS/534/2023), item 1FortAgent can place this verification call on the bank's own telephony, tell the customer they are speaking to an AI agent, and have them confirm with FortAuth on a device they already trust. A person can take over at any point. Each call is transcribed and logged, so the bank can show the customer knew about and approved the change before any transaction went through.FortAgentFortAuth
Customer-service verification that is neither generic nor easy to obtainCORF Chapter 4, clause 8.1.3.4FortAgent verifies the caller through FortAuth on their own device before any account action, rather than with balances or recent transactions, the very examples the clause rejects. A signature from a key held in the caller's phone cannot be researched or socially engineered. CBK's own examples are a registered mobile with a secure PIN, or voice biometrics; this is a different method, so the bank should record it as such.FortAgentFortAuth
MFA before changes to sensitive customer information through the mobile app, IVR or online bankingCORF Chapter 4, clause 8.1.3.5A passkey step-up is the MFA event for a change of mobile number or email address in the app or on the web. On a voice or IVR channel, FortAgent sends the request for a FortAuth confirmation on the customer's device instead of accepting details read out over the phone.FortAuthFortAgent
Customer awareness of AI in products, and AI that is explainable, auditable and monitoredCORF Chapter 4, clauses 7.1.1.7, 7.1.2.4 and 7.1.2.5FortAgent tells every caller they are speaking to an AI agent, and transcribes, QA-scores and audit-trails every call, so each automated decision can be reconstructed and reviewed. It is model agnostic, so the bank chooses, and can switch, the model it monitors. FortVoice shows the transcribed command on the phone for confirmation before it executes, so no voice instruction is acted on unseen.FortAgentFortVoice
Confidentiality of customer data that extends to third parties supporting the bankBank Customer Protection Manual, Section Eighth item 2 and Principle Nine; E-Payment Instructions, Articles 29 and 30An on-premise or in-region deployment keeps authentication data, speech and call records inside the bank's own estate, so there is less third-party holding for the bank to answer for. FortVoice processes speech in the bank's own region rather than at a global endpoint, and FortAuth holds only public keys, which reveal nothing if breached.FortVoiceFortAgentFortAuth
Safe technology, including fingerprint and mobile apps, to help blind and low-vision customers bank independentlyCircular No. (2/BS/IBS/350/2015), Instructions on Dealing with Blind and Low Vision Customers, item 4FortVoice lets a customer speak a banking command inside the app, and it is confirmed before it executes. FortAuth replaces typed codes with a fingerprint or face unlock. Together they let a blind or low-vision customer complete a transaction without reading a screen or an SMS, while keeping the security controls the circular requires.FortVoiceFortAuth
What this mapping does not claim

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.

  • The SMS OTP, 12-hour activation delay and notifications on beneficiary additionCircular No. (2/BS, IBS/534/2023), item 1, still requires an OTP SMS when a beneficiary is added, a notification by SMS, app and email, and no activation for at least 12 hours. That sits awkwardly with CORF clause 8.3.1.3, which names beneficiary addition as a critical action but does not list SMS among its methods. Until CBK says otherwise, passkeys run alongside this SMS step for beneficiary addition rather than replacing it. The delay and notification process remain the bank's.
  • CBK approvals before go-live — emerging technology, cloud and significant IT third partiesCORF Chapter 4, clause 7.1.1.2 (emerging technology including AI, at least one month before go-live), 7.2.1.3 (cloud agreements touching sensitive data, at least one month before signing, including the location of data storage) and 6.1.1.2 (significant IT third-party agreements). E-payment and e-money providers also need prior written approval for cloud under E-Payment Instructions Article 28. These filings are the bank's. We supply the architecture, data-location and risk material they need, and an on-premise deployment is the arrangement least likely to fall within the cloud approval.
  • Incident reporting to CBK within one hour (high severity) or four hours (medium)CORF Chapter 5 Operational Resilience Baselines, clause 8.2.2.1, and Chapter 4 clause 5.11.2.4 for personal data breaches. Reporting is the regulated entity's obligation. Our ceremony logs and call transcripts help establish the facts quickly, but they are not the reporting process.
  • Transaction monitoring, AI-based fraud detection and fraud playbooksCORF Chapter 4, Sub-Domain 8.2. Real-time fraud detection, AI/ML detection models and playbooks covering SIM-swap, AI chatbot and deepfake fraud make up the bank's fraud programme. Our products supply authentication signals and logs that feed it; they are not the programme.
  • Entity certifications, the Complaints Unit and customer awareness campaignsCORF Chapter 4 clause 4.3.1.3 requires regulated entities to hold ISO 27001, ISO 22301 and PCI certifications, and clause 4.5.2.6 requires quarterly customer security awareness campaigns. Circular No. (2/BS/IBS/269/2011) requires a Complaints Unit that gives a written opinion within 30 working days. All three are the bank's own obligations.
  • Data residency for customer or transaction dataNot established. The CORF requires the cloud policy to cover 'compliance with data residency requirements' (Chapter 4, 7.2.1.2(d)), and the approval request to state the location of data storage, but it does not set an in-country rule itself. Neither do the E-Payment Instructions, the circulars or the Customer Protection Manual. No residency claim is made for Kuwait.
  • CITRA Data Privacy Protection RegulationNot cited. The regulation is issued by the Communications and Information Technology Regulatory Authority, not CBK, and is reported to apply to CITRA-licensed service providers. We could not obtain the official text from CITRA, so we make no claim about how it applies to call recordings or transcripts.
Sources

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.

Deployment options in Kuwait

Served from our UAE and Pakistan offices with in-region deployment: on-premise, in-region cloud, or hybrid.

Deployment shapes

On-premiseIn-region cloudHybrid

Runs on

Amazon Web ServicesMicrosoft AzureGoogle Cloud

Deployed 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.

CBK questions, answered.

They are named in it. Clause 8.3.1.3 of the CORF Cyber Resilience Baselines lists three methods for strong MFA and for authorising critical actions such as fund transfers, bill payments and beneficiary addition. The third is device-based authorisation, for example FIDO2, tied to a registered mobile device. A FortAuth passkey is exactly that: a private key in the secure element of the registered phone, unlocked by biometric or PIN. Clause 8.1.2.5 names FIDO2 again for onboarding, and clause 8.3.1.13 asks for biometric login where the device supports it. The one caveat is Circular No. 2/BS, IBS/534/2023, which still requires an SMS OTP on beneficiary addition. Validate against the current text, and note that the Arabic text governs where it differs from CBK's English versions.

Yes, as a deployment choice: all three products run on-premise, in in-region cloud, or hybrid, so authentication data, speech processing and call records can stay in country. On the regulatory side, none of the CBK instruments read for this page sets an in-country hosting rule. The CORF requires a cloud policy that covers data residency requirements, and CBK approval at least one month before signing a cloud agreement that touches sensitive data, including the location of data storage. So for a Kuwaiti bank, the practical question is less where data must be stored and more what the CBK approval will need to show. An on-premise deployment usually answers that most simply.

For sign-in and most critical actions, CBK's own list points that way. SMS OTP appeared in the 2020 Cybersecurity Baselines, but it is not among the three methods in CORF clause 8.3.1.3, and OTPs that are used now expire after two minutes. Beneficiary addition is the exception: Circular 534/2023 still requires an OTP SMS there, plus a 12-hour activation delay. Banks here typically enrol passkeys first for login and payments, keep the SMS step on beneficiary addition until CBK says otherwise, and use the passkey as the in-app security code the same circular asks for.

It cites CBK's own clause numbers, naming the CORF chapter because numbering restarts in each, and links to the CBK-hosted documents. It also keeps what the product does separate from what stays with the bank. The CBK mapping covers CORF clauses 8.3.1.3, 8.1.2.5, 8.3.1.9 to 8.3.1.12, 8.1.3.4, 8.1.3.5 and 7.1.1.7 to 7.1.2.5, Circulars 534/2023, 547/2024 and 350/2015, and the confidentiality provisions of the Customer Protection Manual and E-Payment Instructions. It names what is outside our scope: the CBK approval filings for AI and cloud, incident reporting, the fraud programme, and entity certifications. It also says plainly that CBK has set no data-residency rule and no per-call AI-disclosure rule. FortAgent discloses to callers anyway, as support for clause 7.1.1.7's customer-awareness duty.

Get the CBK control mapping

The full control-by-control mapping for FortAuth, FortVoice and FortAgent, as a document your compliance function can review.

Other markets