BDDK authentication and app-security requirements.
How financial institutions in Turkey meet them with Fortanixor — banks, exchange houses, payment providers, microfinance and fintechs supervised by the Banking Regulation and Supervision Agency.
Regulation ref: Regulation on Banks' Information Systems and Electronic Banking Services (2020)
Turkey is the strictest of the seven markets on authentication, and the closest to PSD2. Article 34 requires two components that are independent of one another and drawn from two different classes — something the customer knows, has, or is — and adds that the possession component must be unique to the customer and impossible to imitate. Independence is defined in the text itself: compromising one component must not compromise the other. The requirement covers non-financial actions too, including simply viewing account information.
The clause that matters most is Article 34(7). For any customer who has installed and activated the mobile banking app, the bank may not send an SMS OTP or verification code at all for sign-in or for confirming a transaction, and may not use one as an authentication component. SMS is permitted only for first installation, activation, re-activation, or when the app is unusable. Article 34(8) adds a 90-day prohibition on SIM-based components after a SIM change or number port until the change is confirmed. A FIDO2 passkey is the natural answer to both: the private key lives in the device secure element, is unlocked by biometric or PIN, and has no dependence on the SIM or on a code in transit. Reading the channel-specific articles closes two questions this page previously left open. Article 38(3) is a dynamic-linking rule in all but name: for transactions with a financial result the verification code must be specific to the amount and payee the customer approved, and any change to either invalidates it — and the code is to be generated signed with a cryptographic private key assigned to the customer, with SMS permitted only where such signing is not possible. Article 39(1) then says that where an app PIN or a biometric unlocks a customer-specific encryption key and that key verifies unique customer information online at the bank, the two-component requirement of Article 34(1) is deemed satisfied. And Article 25(1) is unambiguous on hosting: banks are obliged to keep their primary and secondary systems inside Turkey.
What Banking Regulation and Supervision Agency requires
01 / 06
Two independent components from different classes
Electronic banking, including actions with no financial result such as viewing account information, requires at least two components that are independent of each other and drawn from two different classes — what the customer knows, has, or is. Compromising one must not compromise the other, and the possession component must be unique to the customer and impossible to imitate. Information printed on identity documents, and mother's maiden name, may never be used as a factor.
SMS OTP prohibited once the mobile app is active, and after a SIM change
For customers who have installed and activated the mobile banking app, the bank may not send an SMS one-time password or verification code for sign-in or for confirming any transaction, and may not use one as a factor — SMS survives only for first installation, activation, re-activation, or when the app cannot be used. Separately, banks must integrate with Turkish mobile operators to detect a SIM change or number port, and may not use a SIM-based component for 90 days until the change is confirmed.
Dynamic linking: the code must be specific to the amount and payee
For transactions with a financial result, the verification code must be specific to the amount and the payee the customer approves at the time, and any change to the amount or the payee must render that code invalid. For corporate bulk transfers the code must be specific to the batch total and its payees. The code is to be produced signed with a cryptographic private key assigned to the customer; SMS delivery is permitted only where signing with that key is not possible.
A customer-specific key unlocked by PIN or biometric is deemed two-factor
Where a mobile banking app PIN is used to access a customer-specific encryption key, and unique customer information is verified online at the bank through that key, the two-component requirement is deemed satisfied. The same applies where a biometric unlocks that key. But passwords, PINs or biometric data under the device manufacturer's control rather than the application's may not themselves serve as the knowledge or inherence factor.
Primary and secondary systems must be located in Turkey
Banks are obliged to keep their primary and secondary systems within the country. Every backup of a primary system, at whatever remove, counts as a secondary system and is caught by the same rule. Apart from payment and messaging systems that inherently require interaction abroad, a bank must be able to carry out banking operations through its in-country systems without dependence on any approval from a system established abroad, and even if international network links are severed.
Telephone banking without agent access to credentials
Where telephone banking authentication uses knowledge components, one-time passwords or transaction verification codes, those must be entered through automated systems without the agent being involved or able to see them, and changes to a customer's authentication or telephone details must likewise happen without agent involvement. Call recordings must be of a quality that yields reliable evidence and assigns responsibility, and the bank must use techniques that make non-repudiation possible for both sides.
A FIDO2 passkey ceremony is possession plus inherence in one gesture: the private key is generated in and never leaves the device secure element, and a biometric or PIN unlocks it there. The key is unique per customer per bank and cannot be copied out, which is what 'unique to the customer and impossible to imitate' asks for. Compromising the PIN yields nothing without the device, satisfying the independence test in the same clause.
FortAuth removes the code entirely rather than moving it to another channel, so the prohibition is met by construction. A passkey also has no dependence on the SIM, so a customer who swaps SIM or ports a number keeps authenticating normally through the 90-day restriction, and an attacker holding a replacement SIM gains nothing.
This is what Secure Payment Confirmation does. The amount and payee are bound into the data the customer signs, so the signature is valid only for that instruction and any change to either invalidates it. Article 38(3) also asks for the code to be produced signed with a cryptographic private key assigned to the customer and treats SMS as the fallback where that is not possible — a passkey is that assigned key, so the bank sits in the article's preferred path rather than its exception.
Article 39(1) describes the FortAuth model and then deems it to satisfy the two-component requirement: an app PIN or a biometric unlocks a customer-specific key, and unique customer information is verified online at the bank through it. A FIDO2 passkey is exactly that — a per-customer private key in the device secure element, unlocked locally, with the resulting signature verified server-side. Note the constraint in 39(2): the PIN or biometric must be under the application's control, not the device manufacturer's, which is a deployment decision to make with your mobile team.
Passkey credentials are bound to the bank's origin, so the browser will not release them to a spoofed domain and there is no authentication data in transit to keep confidential in the first place.
Enrolling an additional passkey is itself a passkey ceremony from an already-bound device, so registration meets the same two-component bar as the sign-in it protects.
Each ceremony produces a signature made by a key that exists only in the customer's device, together with a log entry recording the result and reason. That is a stronger basis for assigning responsibility than a delivered-message receipt, which shows only that a code was sent to a number.
FortAgent verifies the caller through FortAuth on their own device before any account action, so the credential is never spoken to, seen by, or entered through a person. The AI agent is not a person for the purposes of this clause, and the passkey ceremony happens outside the call audio entirely.
Every FortAgent call is transcribed, scored and summarised with a full audit trail, and FortVoice logs the instruction it understood alongside the FortAuth step-up that authorised anything that moved money.
All three products deploy on-premise or into in-region cloud, so the verifying infrastructure and its backups can sit inside Turkey as Article 25 requires. The customer's own private key never leaves their device, so the most sensitive credential in the system is not hosted anywhere at all — and FortVoice processes speech in the bank's own region rather than shipping audio to a global endpoint.
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.
Integration with Turkish mobile operators to detect SIM changesArticle 34(8). The obligation to establish that integration sits with the bank and its operator relationships. A passkey removes the dependency the clause is protecting against, but it does not discharge the integration duty itself, which still applies to any remaining SMS path such as first activation.
Operating the in-country systems themselvesArticle 25 obliges the bank to hold its primary and secondary systems in Turkey. Our products deploy into that estate; standing it up, and proving the bank can still operate if international links are cut, is the bank's. The localisation requirement itself is now mapped above rather than left unestablished.
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 Turkey
Served from our Gulf and Pakistan offices, deployable on-premise, in 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.
BDDK questions, answered.
A FIDO2 passkey ceremony provides two components from two different classes — possession of the device that holds the private key, and the biometric or PIN that unlocks it in the secure element — which is the structure Article 34(1) sets out. It also meets the harder parts of that clause: the components are independent, because compromising the PIN is useless without the device, and the possession component is unique to the customer and cannot be imitated, because the private key is generated inside the secure element and cannot be exported. The mapping must still be validated by your compliance function against the current version of the regulation.
For customers who have installed and activated the mobile banking app, yes. Article 34(7) says the bank may not send an SMS OTP or verification code for sign-in or for confirming any transaction, and may not use one as an authentication component. SMS survives only for first installation, activation, re-activation, and when the app cannot be used. Turkey is the only one of our seven markets with a prohibition this explicit — SAMA, Bangladesh Bank, SBP, QCB and CBUAE all still permit one-time codes — so a passkey rollout in Turkey is a compliance requirement rather than an upgrade.
Article 34(8) requires the bank to detect a SIM change or number port through integration with Turkish mobile operators, and then to refuse any SIM-based authentication component for 90 days until the change is confirmed. With SMS OTP that is a 90-day degradation of service for a legitimate customer who simply changed phone plans. With a passkey there is nothing SIM-based in the authentication path at all, so the customer keeps signing in normally while the SIM-based restriction runs its course.
It reads article by article in BDDK's own numbering and separates what the product does from what stays with the bank. The downloadable BDDK mapping covers Articles 25, 34, 35, 38, 39 and 40, and names what remains the bank's — the mobile-operator integration in Article 34(8) and standing up the in-country systems Article 25 requires. Two things are worth your compliance function's attention: Article 38(3)'s dynamic linking, which Secure Payment Confirmation answers directly, and Article 39(2)'s rule that the PIN or biometric must be under the application's control rather than the device manufacturer's, which shapes how the mobile integration is built.
Get the BDDK control mapping
The full control-by-control mapping for FortAuth, FortVoice and FortAgent, as a document your compliance function can review.
