How financial institutions in Bangladesh meet them with Fortanixor — banks, exchange houses, payment providers, microfinance and fintechs supervised by the Bangladesh Bank.
Regulation ref: Guideline on ICT Security v4.0 (2023)
Bangladesh Bank's ICT Security Guideline is organised by domain, and the clause that matters most for authentication is short and unambiguous. Section 11.4.6 requires multi-factor authentication for all online financial transactions — the transaction, not merely the login. That is a stronger and more explicit transaction-level requirement than SAMA's or SBP's, and it is where a passkey earns its place. Section 11.4.7 adds that a session must terminate after a fixed period unless the customer is re-authenticated, and 11.4.10 and 11.4.11 require measures against man-in-the-middle attacks and session hijacking.
The second thing that sets Bangladesh apart is Section 11.7.4, the SIM-swap clause. Banks must agree a SIM replacement process with the mobile network operators, including prior notification and confirmation, specifically to protect the MFS account from unwanted transactions. It is an unusually direct acknowledgement that a code sent to a phone number is only as strong as the operator's SIM process. A passkey removes that dependency entirely: there is no code sent to a number, so a replaced SIM confers nothing. Bangladesh is also the one market of the seven that publishes genuine AI governance clauses — Section 14.1.2 — which is why the FortAgent mapping here cites named requirements rather than general ones.
The organisation must implement multi-factor authentication for all online financial transactions, and must assure customers that online access and transactions performed over the internet are adequately protected and authenticated. Mechanisms adopted must be well-established international standards.
An online session must be automatically terminated after a fixed period unless the customer is re-authenticated for the session to be maintained. Secure session management techniques must prevent session hijacking, including unique session identifiers, secure cookies and enforced timeouts.
The organisation must arrange an agreement with the mobile network operators about the SIM replacement process, including sending prior notification and getting confirmation, to ensure appropriate measures for the MFS account and avoid the risk of unwanted transactions. Mobile services must comply with the authentication practices mandated by the regulator.
A standard architecture based on security principles must be used to design a secure mobile application. Misconfigured devices must be denied access to enterprise resources, and a device attempting access in an insecure state must be actively refused. Auto-complete must be off for login IDs and passwords, and clipboard or copy-paste disabled for sensitive data.
Where AI is used — the guideline names chatbots and voice bots in the front end for customer identification and authentication — safeguards must prevent corruption or malicious use of the algorithm, human judgment must be applied to faulty or biased results, AI systems must be continuously monitored and operated by qualified human resources, and a fallback plan must exist for model drift or unexpected input shift.
ICT Security Guideline, Section 14.1.2.1, 14.1.2.2, 14.1.2.4 and 14.1.2.7
A centralised log management system must collect events from servers, network devices, operating systems, databases and applications into a single repository, with a common accurate time source for correlation. Log data must be archived and retained according to the organisation's own log retention policy. Before any cross-border service agreement, approval must be taken from Bangladesh Bank under the outsourcing guidelines.
| Requirement | Framework reference | How Fortanixor addresses it | Product |
|---|---|---|---|
| Multi-factor authentication for all online financial transactions | Section 11.4.6 | 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 — and it runs on the transaction, not only at the door, which is what this clause asks for. | FortAuth |
| Authentication mechanisms that are well-established international standards | Section 11.4.3 | FIDO2 and WebAuthn are open standards published by the FIDO Alliance and the W3C, implemented natively across browsers and mobile platforms. Fortanixor's implementation is FIDO2 certified against the published specification — an independent conformance test, not a self-assertion. | FortAuth |
| Measures against man-in-the-middle attacks and session hijacking | Section 11.4.10 and 11.4.11 | Passkey credentials are bound to the bank's origin, so a lookalike domain cannot complete a sign-in and there is no credential in transit to intercept. Each authorisation is a fresh signature rather than a bearer token that can be lifted from a session. | FortAuth |
| Re-authentication to maintain a session past a fixed period | Section 11.4.7 | Re-authentication is a single biometric touch rather than a re-typed password and a re-sent code, so enforcing a short session lifetime costs the customer almost nothing — which is what makes the control survive contact with real usage. | FortAuth |
| Protecting the MFS account against SIM replacement risk | Section 11.7.4 | A passkey has no dependency on the SIM or the mobile number. There is no code sent to a phone number, so a replaced SIM gives an attacker nothing to authenticate with, and the control no longer rests on the operator's replacement process working correctly. | FortAuth |
| Insecure devices refused, and no credential left on the device to auto-complete or copy | Section 11.7.8, 11.7.10 and 11.7.11 | Optional device fingerprinting and VPN or anonymiser detection feed the decision to refuse a compromised device, and Android FLAG_SECURE blocks screen capture during the ceremony. There is also no login ID or password to auto-complete and no one-time code to copy: the credential is a private key the customer never sees or types, which removes the exposure these clauses are written to contain rather than suppressing the symptom. | FortAuth |
| Human judgment applied to faulty or biased AI results, with continuous monitoring by qualified people | Section 14.1.2.2 and 14.1.2.4 | FortAgent hands off to a person at any point, and every call is transcribed, scored and summarised so a supervisor reviews outcomes rather than sampling blind. Scoring is what makes continuous monitoring practical at call volume. | FortAgent |
| Safeguards so an AI application cannot be corrupted or used in malfeasant ways | Section 14.1.2.1 | FortAgent operates under policy controls and allow-listed tools, so the agent can only take the actions the bank has enumerated. A prompt that talks the model into something outside that list still cannot reach an account action. | FortAgent |
| Sensitive personal information difficult to reveal from the AI system | Section 14.1.2.5 | The caller is verified through FortAuth on their own device before any account data is reached, so the agent does not disclose account information to an unverified caller. FortVoice processes speech in the bank's own region rather than sending audio to a global endpoint. | FortAgentFortVoice |
| Centralised log collection with an accurate common time source | Section 5.17.1 and 5.17.2 | Every authentication ceremony and every agent call produces a timestamped record that exports into the bank's existing central log repository and SIEM, rather than sitting in a product-local store the correlation cannot see. | FortAuthFortAgent |
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.
Section 11.4.6 requires multi-factor authentication for all online financial transactions, and a FIDO2 passkey ceremony is two 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. Note the scope of that clause: it attaches to the transaction, not just the login, so the check has to run on the payment itself. Section 11.4.3 additionally requires mechanisms that are well-established international standards, which FIDO2 and WebAuthn are. The mapping must still be validated by your compliance function against the current version of the guideline.
Yes. All three products deploy on-premise, in in-region cloud, or hybrid, so authentication data, speech processing and call records can stay in country. On the regulatory position we should be precise: Section 12.5.5 requires Bangladesh Bank approval before establishing any cross-border service agreement, which is an approval gate rather than a flat residency mandate, and we have not yet read Section 5.2 on data centre management in full. So an in-country deployment keeps you clear of the approval gate; we do not claim more than that.
It can, and it addresses a risk the guideline names directly. Section 11.7.4 requires banks to agree a SIM replacement protocol with the mobile operators specifically to stop SIM swap being used against an MFS account — an acknowledgement that a code sent to a number is only as strong as the operator's process. A passkey removes the number from the authentication path altogether. Banks here typically enrol passkeys alongside the existing PIN or OTP, move sign-in first, then the financial transactions Section 11.4.6 covers, and retire the SMS path once enrolment is high enough.
It cites Bangladesh Bank's own section numbering, links to the guideline itself, and separates what the product does from what stays with the bank. The downloadable mapping covers Sections 5.17, 11.4, 11.7, 12.5 and 14.1, and it names what is outside our scope — the mobile-operator agreement, the retention policy, the cross-border approval. Bangladesh is also the one market of the seven where the AI clauses in Section 14.1.2 are real published requirements, so the FortAgent rows here cite named clauses rather than general principles.
The full control-by-control mapping for FortAuth, FortVoice and FortAgent, as a document your compliance function can review.
