How financial institutions in Jordan meet them with Fortanixor — banks, exchange houses, payment providers, microfinance and fintechs supervised by the Central Bank of Jordan.
Regulation refs: Cybersecurity Framework for Jordan Financial Sector v1.0 (2021); Guidance on Combating Financial Fraud in the National Payment System (2023); Bylaw of Electronic Payment and Money Transfer No. 111 of 2017
Jordan is the market where the regulator has said the quiet part out loud. The Central Bank's May 2023 Guidance on Combating Financial Fraud tells payment companies to conduct strong customer authentication using at least two factors and to avoid relying solely on one-time passwords sent via SMS, implementing additional factors according to the degree of risk. It then lists the moments where that applies, including establishing a business relationship, accessing electronic channels through mobile apps or websites, performing financial and non-financial transactions, issuing a new payment card, and reactivating a dormant account.
Underneath the guidance sits the Bylaw of Electronic Payment and Money Transfer No. 111 of 2017, which is the binding instrument. Article 35(b) requires the payment service provider to ensure that the personal security data used to verify the customer's identification are not made available to others, and Article 35(c) requires an authorisation from the customer before a payment order is executed on their account — with the provider liable to refund the money if it cannot show one. A FIDO2 passkey answers both directly: there is no shared security datum that could be made available to anyone, because the private key never leaves the customer's device, and each authorisation is a signature that evidences the customer's consent to that specific payment.
What Central Bank of Jordan requires
01 / 06
Strong customer authentication, not SMS OTP alone
Companies must conduct strong customer authentication using at least two factors and avoid relying solely on one-time passwords sent via SMS, adding factors by degree of risk. The Cybersecurity Framework then defines the bar precisely: authentication counts as multi-factor if and only if it combines at least two authenticators of different factors — anything else is merely multi-step. It lists a cryptographic authenticator, where the individual proves possession and control of a stored private key, as a 'something you have' factor, and physical biometrics as 'something you are'.
A third authentication factor should be required where a login attempt to electronic channels is detected as an anomalous session — a device ID or location differing from previously known parameters, or an IP address flagged as a risk — or where a transaction is instructed from a non-trusted device.
Security data that cannot be made available to others
The payment service provider must ensure that the personal security data used to verify the customer's identification are not made available to others. The obligation is absolute in the text — it does not turn on the provider having taken reasonable care.
Demonstrable customer authorisation before a payment executes
The provider must ensure the existence of an authorisation by the customer before executing a payment order on their account. Without one, the provider is responsible towards the payer and is obliged to refund the money of the payment order in the same currency, on terms the Central Bank sets.
The company must inform the Central Bank and other relevant agencies of any cases of breach or fraud to which it, or any third party contracted with it, may be exposed, as soon as such cases emerge.
Customer confidentiality across contracted third parties
The company must observe full confidentiality of all transactions relating to its customers, binding its board, present and former employees, contracted third parties and insiders. Disclosure or enabling access is prohibited, and the prohibition survives the end of the customer relationship.
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 contains no one-time password at all, so the reliance the guidance warns against is removed rather than supplemented.
A FIDO2 passkey is exactly the pairing the Framework describes. The credential is a cryptographic authenticator under clause 7.2 — the customer proves possession and control of a stored private key — and the biometric that unlocks it in the secure element is a 'something you are' factor under 7.3. Two authenticators of different factors, in one gesture, which is the 'if and only if' test in 7.4. A password followed by an SMS code, by contrast, risks being multi-step rather than multi-factor once the code is delivered to the same device.
One passkey credential covers the mobile app and the web through cross-device QR sign-in, so the same standard of authentication applies on both channels instead of the browser falling back to a weaker path.
Enrolment binds the passkey under a multi-factor ceremony, and the same ceremony can be required at each listed trigger. The event log records which trigger prompted each challenge, so the control is evidenced per event rather than asserted as policy.
Optional device fingerprinting and VPN or anonymiser detection identify the unfamiliar device, location or flagged address that this clause describes, and a fresh passkey step-up on a trusted device supplies the additional assurance without falling back to an SMS code.
There is no shared secret to become available to anyone. The private key is generated inside the device secure element and cannot be exported, and the provider holds only the corresponding public key, which discloses nothing if breached.
Each authorisation produces a signature from a key that exists only on the customer's device, and with Secure Payment Confirmation the amount and payee are bound into the signed data. That is materially stronger evidence of authorisation than a record that a code was sent to a number — which matters here, because the same article puts the refund liability on the provider that cannot show one.
Every authentication ceremony is logged with its result and failure reason, and every agent call is transcribed and scored, so the provider can establish what happened and when quickly enough to notify while the case is still emerging.
An on-premise or in-region deployment keeps customer transaction data inside the provider's own estate rather than creating another contracted party holding it. FortVoice processes speech in the provider's own region rather than sending audio to a global endpoint.
FortAgent verifies the caller through FortAuth on their own device before any account action, so confidential transaction detail is not disclosed on the strength of knowledge-based questions a fraudster can research.
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.
Transaction monitoring, fraud risk scoring and the wider anti-fraud programmeCombating Financial Fraud Guidance. The Guidance is a fraud programme, not an authentication standard — governance, staff training, customer awareness and monitoring all sit with the company. Our products supply authentication and the signals and logs that feed monitoring; they are not the programme.
Commission disclosure, payment order execution and refund handlingBylaw Articles 34 and 35(a). Core payment-processing obligations of the provider, unrelated to authentication.
Customer awareness guidance on PINs, cards and phishingCombating Financial Fraud Guidance, general precautions. Customer communications remain the provider's.
Data residency for customer or transaction dataNot established, and now checked across all three instruments. The Cybersecurity Framework for Jordan Financial Sector v1.0 was the outstanding unknown here; it has now been read and contains no in-country hosting or data-residency requirement, as neither does the Combating Financial Fraud Guidance or Bylaw No. 111. No residency claim is made for Jordan.
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 Jordan
Served from our Gulf and Pakistan offices with in-region deployment: on-premise, in-region cloud, or hybrid.
Deployment shapes
On-premiseIn-region cloudHybrid
Runs on
Microsoft 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.
CBJ questions, answered.
The May 2023 Guidance asks for strong customer authentication using at least two factors and specifically for companies to avoid relying solely on SMS one-time passwords. The Cybersecurity Framework is more precise: under Section G.3.2 clause 7.4, authentication is multi-factor if and only if it combines at least two authenticators of different factors, and clause 7.2 lists a cryptographic authenticator — proving possession and control of a stored private key — as a valid 'something you have'. A FIDO2 passkey is that authenticator, unlocked by a biometric under 7.3, so it meets the test in a single gesture. It also answers Article 35(b) of Bylaw No. 111, because there is no shared security datum that could be made available to others. Validate against the current version of each document, and note the Bylaw's English text is a translation — the Arabic version governs.
Yes as a deployment matter: 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 position we can now be definitive rather than cautious — the Cybersecurity Framework for Jordan Financial Sector v1.0 has been read in full alongside the Combating Financial Fraud Guidance and Bylaw No. 111, and none of the three contains a data-residency or in-country hosting requirement. So this is a capability we offer, not a rule we are meeting.
In Jordan that is the direction the regulator is already pointing. Section C of the 2023 Guidance tells companies to avoid relying solely on SMS one-time passwords and to add factors according to risk, and Section D asks for a third factor on anomalous sessions — a requirement that gets expensive if every escalation is another SMS. Providers here typically enrol passkeys alongside the existing OTP, move channel access first, then the listed transaction triggers, and retire the SMS path once enrolment is high enough.
It cites CBJ's own article and section numbering, links to the Bylaw and the Guidance, and separates what the product does from what stays with the provider. The downloadable CBJ mapping covers Sections C and D of the 2023 Guidance and Articles 35 and 36 of Bylaw No. 111, and it names what is outside our scope — the wider fraud programme, payment execution and refunds, customer awareness. Where a claim rests on an English translation rather than the governing Arabic text, we say so.
Get the CBJ control mapping
The full control-by-control mapping for FortAuth, FortVoice and FortAgent, as a document your compliance function can review.
