Skip to main content
Central Bank of Bahrain

CBB authentication and app-security requirements.

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

Regulation refs: CBB Rulebook Volume 1 (Conventional Banks), Module OM — Operational Risk Management, incl. OM-3 Electronic Banking and OM-5.5 Cyber Security; CBB Rulebook Volume 2 (Islamic Banks), Module OM — Operational Risk Management; CBB Rulebook Volume 1, Module BC — Business and Market Conduct; CBB Rulebook Volume 5 (Ancillary Service Providers), Module GR, incl. the two-factor authentication requirements effective 1 December 2023 (Letter OG/240/2023); Personal Data Protection Law, Law No. (30) of 2018

Bahrain regulates authentication by outcome rather than by naming a technology. Paragraph OM-3.2.4 of the CBB Rulebook, which applies in the same words to conventional banks (Volume 1) and Islamic banks (Volume 2), requires a strong customer authentication process for e-banking in which nothing about the other authentication elements can be derived from the authentication code, no new code can be generated from knowledge of earlier ones, and the code cannot be forged. OM-3.2.2 adds that transaction authentication must promote non-repudiation and establish accountability. The rulebook names neither SMS OTP nor FIDO2. A passkey signature fits these properties closely: it is computed fresh for each challenge by a private key that never leaves the customer's phone, and it cannot be produced without that key.

Payment service providers have had their own rule since 1 December 2023. GR-12.1.3 in Volume 5 requires at least two of knowledge, possession and inherence when a customer accesses a digital platform or starts a transaction, and GR-12.1.5 says a mobile device registered as trusted through the licensee's app counts as the possession element. The rulebook also reaches the phone channel: OM-5.1.2A requires retail banks to counter phishing by telephone and SMS, OM-3.2.2 calls for 'call backs' where appropriate to prevent transfer fraud, and Module OM-2 lists customer call centres among the support activities a bank may outsource under CBB approval or notification. We found no CBB rule specific to AI. Call recordings and transcripts fall under the Personal Data Protection Law, Law No. 30 of 2018, which OM-3.1.2(e) points to.

What Central Bank of Bahrain requires

01 / 06

Strong customer authentication for e-banking that cannot be derived, replayed or forged

Banks must authenticate the identity and authorisation of their customers, and run a strong customer authentication process for e-banking in which no information about the authentication elements can be derived from the code, no new code can be generated from earlier ones, and the code cannot be forged. Security features are expected for each of the three elements: knowledge (PIN or password complexity), possession (algorithm specifications, key length and entropy) and inherence (biometric sensor and template protection). The CBB may allow simplified authentication below quantitative thresholds on a case-by-case basis.

CBB Rulebook Volume 1 and Volume 2, Module OM, paragraphs OM-3.2.1, OM-3.2.4, OM-3.2.5 and OM-3.2.6

02 / 06

Two-factor authentication for PSPs, with a trusted device as possession

From 1 December 2023, payment service providers must authenticate customers when they access the online or digital platform and when a transaction is initiated, using at least two of knowledge, possession and inherence. The elements must be independent, so that the breach of one does not compromise the others, and complex enough to prevent forgery. A mobile device registered as trusted through the licensee's own app, using knowledge, biometric or other methods, meets the possession element for future access and transactions on that device.

CBB Rulebook Volume 5, Module GR, paragraphs GR-12.1.3, GR-12.1.4 and GR-12.1.5; Letter OG/240/2023

03 / 06

Non-repudiation, call-backs and audit trails for electronic transfers

Transaction authentication methods must promote non-repudiation and establish accountability. Banks need detailed procedures to identify the person originating an electronic funds transfer, and for call-backs where appropriate to prevent fraud. Clear audit trails must exist for all electronic transfers and e-banking transactions, and log retention must capture the source of each request, synchronised time and all related metadata.

CBB Rulebook Volume 1 and Volume 2, Module OM, paragraphs OM-3.2.2, OM-3.3.4 and OM-3.3.5

04 / 06

Countering phishing by telephone, SMS and links

Retail banks must take measures against phishing attempts made by telephone or WhatsApp calls, SMS or WhatsApp messages and email that ask customers for sensitive information, and must watch for the account activity those attempts cause. Links in SMS and similar messages are limited to messages the customer triggered, shortened links are barred, and each link must carry at least one safeguard, such as transaction details in the message or verification by password or biometric authentication. PSPs carry the same link rules.

CBB Rulebook Volume 1 and Volume 2, Module OM, paragraphs OM-5.1.2A and OM-5.5.21; Volume 5, Module GR, paragraph GR-12.2.26

05 / 06

Outsourcing of call centres, data processing and cloud

The CBB names customer call centres, data processing and cloud services as typical outsourced activities. Support activities may be outsourced, but strategic decisions and the principal risks stay with the licensee. Outsourcing to a third party outside Bahrain, other than cloud data services, needs prior CBB approval requested at least 30 calendar days ahead. Outsourcing within Bahrain, and to cloud data service providers inside or outside Bahrain, needs notification within 5 working days of signing. Every arrangement needs an SLA covering confidentiality and encryption, with unrestricted access for the CBB and auditors.

CBB Rulebook Volume 1 and Volume 2, Module OM, paragraphs OM-2.1.2, OM-2.1.5 and OM-2.1.7; Volume 5, Module GR, paragraphs GR-11.1.2, GR-11.1.5 and GR-11.1.7

06 / 06

Customer data confidentiality under the PDPL

E-banking policies must include measures that protect customer data confidentiality consistent with Law No. 30 of 2018, the Personal Data Protection Law, and confidentiality measures must match the sensitivity of the data stored or transmitted. The PDPL requires appropriate technical and organisational security measures, a written contract binding any data processor to equivalent security and confidentiality, and restricts transfers of personal data outside Bahrain to countries the Authority recognises as adequate or to transfers it authorises.

CBB Rulebook Volume 1 and Volume 2, Module OM, paragraphs OM-3.1.2(e), OM-3.3.6 and OM-3.3.8; Personal Data Protection Law (Law No. 30 of 2018), Articles 8 and 12

Control mapping

How Fortanixor maps to CBB requirements.
RequirementFramework referenceHow Fortanixor addresses itProduct
An authentication code from which nothing about the other elements can be derived, which cannot be generated from earlier codes, and which cannot be forgedVolume 1 and Volume 2, OM-3.2.4(a) to (c)A FortAuth passkey answers each login or payment with a signature over a fresh server challenge, made by a private key held in the secure element of the customer's phone. The signature reveals nothing about the key, the PIN or the biometric. Past signatures do not help produce the next one, and without the key none can be forged. Because the credential is bound to the bank's domain, a lookalike site gets nothing it can replay.FortAuth
Security features for the knowledge, possession and inherence elementsVolume 1 and Volume 2, OM-3.2.6(a) to (c)Possession is the non-exportable key on the registered device, using standard public-key algorithms and key lengths the bank can document. Inherence is the device's fingerprint or face match, which runs on the phone's own sensor and protected template store and never sends the biometric to the bank. The device PIN is the knowledge fallback. The bank can document the algorithm and key length OM-3.2.6 asks about from the FIDO2 standard and the credential it registers, and the sensor and template protection from the device platform's own specifications.FortAuth
PSPs: at least two independent elements at access and at transaction initiation, with a trusted device counting as possessionVolume 5, GR-12.1.3, GR-12.1.4 and GR-12.1.5Registering a passkey through the PSP's app is the act of marking the device as trusted that GR-12.1.5 describes. After that, each sign-in or payment combines possession of the key with a biometric or PIN unlock, which are two independent elements in one gesture. A stolen password does not compromise the key, and a stolen phone without the owner's biometric or PIN cannot use it.FortAuth
Predefined transaction authentication that promotes non-repudiation and accountabilityVolume 1 and Volume 2, OM-3.2.2With Secure Payment Confirmation, the amount and payee are shown on the customer's device and bound into the data the passkey signs, so the record shows what the customer approved, not just that a code was entered. FortVoice applies the same principle to spoken instructions: the transcribed command is shown on the phone and executes only after the customer confirms it.FortAuthFortVoice
Call-backs, where appropriate, to identify the person originating an electronic funds transferVolume 1 and Volume 2, OM-3.2.2FortAgent can place the call-back on the bank's own telephony, tell the customer they are speaking to an AI agent, and ask them to confirm the transfer with FortAuth on their registered phone. A person can take over at any point. When to call back stays the bank's decision under its own procedures; every call is transcribed and logged against the transfer it concerns.FortAgentFortAuth
Clear audit trails for electronic transactions, with the source of each request, synchronised time and metadataVolume 1 and Volume 2, OM-3.3.4 and OM-3.3.5FortAuth logs each ceremony with the credential and device used, the time, the origin and the signed challenge. FortVoice logs the transcribed command alongside the customer's confirmation. FortAgent transcribes, QA-scores and audit-trails every call. These records can go to the bank's own log and retention systems, so the retention period follows the bank's documented policy.FortAuthFortVoiceFortAgent
Measures against phishing by telephone, WhatsApp, SMS and email that seeks customers' sensitive informationVolume 1 and Volume 2, OM-5.1.2AWith passkeys there is no one-time code for a fraudster to ask the customer to read out, and a credential bound to the bank's domain will not sign for a phishing site. In the contact centre, FortAgent verifies callers through FortAuth on their own device instead of asking for details a fraudster could have phished first. The surveillance and monitoring duty in the same paragraph remains the bank's.FortAuthFortAgent
Safeguards on links sent by SMS and short messages, including verification by password or biometric authenticationVolume 1 and Volume 2, OM-5.5.21(c)(iii) and (iv); Volume 5, GR-12.2.26A payment link the customer requested opens to a passkey approval: biometric authentication that the rule names in item (iv), with the amount and merchant shown on the device as item (iii) asks of the message. A link sent by anyone other than the bank leads to a site the passkey will not sign for.FortAuth
Checking the authenticity of an electronic request to reactivate a dormant account, for example by telephone or video callVolume 1, BC-4.20.11FortAgent can call the customer on the number the bank holds, disclose that it is an AI agent, and ask for a FortAuth confirmation on a device the bank already trusts. The transcript and signed confirmation together record how authenticity was established. Where no registered device exists, the agent hands the call to staff.FortAgentFortAuth
Customer data confidentiality consistent with the PDPL, including processor contracts and limits on transfers outside BahrainVolume 1 and Volume 2, OM-3.1.2(e) and OM-3.3.6; PDPL Articles 8 and 12An on-premise or in-region deployment keeps speech, call recordings, transcripts and authentication logs inside the bank's chosen estate, so no transfer abroad is needed to run the products. FortVoice processes speech in the bank's own environment rather than at a global endpoint. FortAuth stores only public keys, which reveal nothing if breached, and never receives the customer's biometric.FortVoiceFortAgentFortAuth
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.

  • Free SMS transaction advice on every withdrawal and paymentVolume 1, BC-4.10.1 requires retail banks to send an SMS advice, at no charge, for all withdrawals and deductions, including payments through mobile, internet or other electronic means. This is a notification, not an authentication step, and passkeys do not replace it. It stays in place.
  • CBB approval or notification for outsourcingVolume 1 and Volume 2, OM-2.1.7, and Volume 5, GR-11.1.7: prior approval at least 30 calendar days ahead for outsourcing to a third party outside Bahrain (excluding cloud data services), and notification within 5 working days for outsourcing within Bahrain or to cloud data service providers. Whether a deployment is outsourcing, and the filing itself, are the licensee's. We supply the due-diligence, data-location and SLA material, and a managed FortAgent service is the arrangement most likely to count as outsourcing a call centre.
  • Cyber incident reporting to the CBB within one hourVolume 1 and Volume 2, OM-5.5.57 and OM-5.5.58 (contact the CBB within one hour, full report within 10 calendar days); Volume 5, GR-12.2.59. Reporting is the licensee's obligation. Our logs and transcripts help establish the facts quickly, but they are not the reporting process.
  • Fraud monitoring limits, customer fraud awareness and PCI-DSS certificationOM-3.1.2(f) and GR-12.1.1 require enhanced fraud monitoring with limits on value, volume and velocity; OM-3.3.11, OM-5.1.2B and GR-12.1.2 require customer awareness campaigns; OM-5.1.1 requires retail banks to hold PCI-DSS certification. These are the licensee's own programmes and certifications. Our products feed authentication signals into them; they are not the programme.
  • AI-specific rules, including disclosure to callersNot established. We found no artificial intelligence or machine learning provision in Modules OM, BC, FC or GR, and no AI directive or consultation on cbb.gov.bh. FortAgent discloses to every caller that it is an AI agent as good practice, not because a CBB rule we read requires it. PDPL Article 22 gives a right to object to decisions based solely on automated processing about matters such as creditworthiness; FortAgent does not take such decisions.
  • PDPL notification and prior authorisation filingsPDPL Article 14 requires prior notice to the Personal Data Protection Authority of automated processing, and Article 15 requires prior written authorisation for, among other things, automatic processing of biometric data to verify identity. These filings are the data controller's. In a passkey ceremony the biometric is matched on the customer's phone and never reaches the bank, but whether Article 15 applies to a given deployment is for the bank and the Authority to decide.
  • Data residency for customer or transaction dataNo in-country hosting rule was found in the CBB modules read. OM-2.1.7 treats outsourcing abroad as needing prior approval, while cloud data services need only notification, and PDPL Article 12 restricts transfers of personal data outside Bahrain. No residency claim beyond these is made for Bahrain.
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 Bahrain

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.

CBB questions, answered.

They match its terms closely. OM-3.2.4 asks for an authentication code that reveals nothing about the other elements, cannot be generated from earlier codes and cannot be forged. A passkey signature is made fresh for each challenge by a private key that never leaves the customer's phone, so it has all three properties. It also combines possession of the key with a biometric or PIN, the elements OM-3.2.6 lists. For PSPs, GR-12.1.5 says outright that a device registered as trusted through the licensee's app is the possession element. The CBB does not name FIDO2, so validate the mapping against the current rulebook text.

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 where the bank decides. On the regulatory side, the CBB modules we read set no in-country hosting rule. Two rules shape the decision. OM-2.1.7 requires prior CBB approval for outsourcing to a third party outside Bahrain, with cloud data services needing only notification, and Article 12 of the Personal Data Protection Law restricts transfers of personal data outside the Kingdom. An on-premise deployment usually avoids both questions.

For sign-in and payment approval, it can. The rulebook sets properties, not a channel, and names neither SMS OTP nor FIDO2, so a bank can move to passkeys without a CBB rule forcing or forbidding SMS. Two SMS duties are separate and stay. BC-4.10.1 requires a free SMS advice after every withdrawal and payment, which is a notification, not an authentication step. OM-5.5.21 limits links sent by SMS, and approving a link with a passkey biometric is one of the safeguards it lists. Banks usually enrol passkeys for login and payments first and keep SMS for alerts.

It cites the CBB's own paragraph numbers, names the rulebook volume because banks, Islamic banks and PSPs sit in different volumes, and links to the rulebook text. It keeps what the product does separate from what stays with the licensee. The Bahrain mapping covers OM-3.2.2, OM-3.2.4, OM-3.2.6, OM-3.3.4, OM-3.3.5, OM-5.1.2A and OM-5.5.21 in Volumes 1 and 2, GR-12.1.3 to GR-12.1.5 in Volume 5, BC-4.20.11, and Articles 8 and 12 of the PDPL. It names what is outside our scope: outsourcing filings, one-hour incident reporting, fraud monitoring, PCI-DSS and the PDPL filings. It also says plainly that we found no CBB rule on AI.

Get the CBB control mapping

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

Other markets