Our engineers set up and run your first chatbot / LLM security scan. Get in touch

BDDK and AI security: testing the LLM layer in Turkish banks

BDDK's information-systems regulation requires banks in Turkiye to run periodic penetration tests and manage technology risk. The regulation predates LLM features - but the obligation lands on them the moment a bank ships a customer chatbot, a fraud-triage assistant, or an internal copilot.

Last reviewed July 2026

Why the classic BDDK pentest misses the AI layer

The periodic penetration test a bank commissions for its BDDK information-systems obligations is scoped to networks, applications, and infrastructure. It is a dated snapshot, and it does not speak the AI layer's language: nobody in a standard engagement attempts Turkish-language prompt injection against the customer chatbot, probes the fraud assistant for excessive tool permissions, or checks whether the policy-document RAG returns content across business-line boundaries.

Meanwhile the model behind those features updates on the vendor's schedule, not the bank's test calendar. A behaviour that passed in the March engagement can reopen in June with no code change on the bank's side. For a regulator whose framework expects managed, tested, evidenced technology risk, "we pentested in March" is a weak answer about a system that changed in April.

What continuous AI-layer testing adds for a bank

The complement that fits the BDDK posture is scheduled adversarial testing of the AI surface itself, producing dated evidence between annual engagements. Probes run in Turkish and English against the bank's real endpoints - injection attempts against the chatbot, data-extraction attempts against RAG copilots, tool-abuse sequences against agents - and every finding is recorded with severity, evidence, and remediation status in an append-only log.

The runtime side complements the audit file: a self-hosted gateway inside the bank's network enforces data-loss prevention on live LLM traffic (card numbers, IBAN, TC Kimlik) without prompt content ever leaving the trust boundary - a control a bank can demonstrate to an auditor, with block logs as operating evidence. Deployment fits bank constraints: the gateway ships as a VM appliance or container, runs air-gapped-friendly, and verifies Ed25519-signed policy before loading anything.

BDDK capabilities

Scheduled adversarial scans between annual pentest engagements, evidence dated and append-only

Turkish + English probe variants against chatbots, RAG copilots, and agent tool-chains

Self-hosted runtime gateway: prompts stay in the bank network; DLP for card/IBAN/TC Kimlik patterns

Findings pre-mapped to EU AI Act, ISO/IEC 42001, NIST AI 600-1, OWASP LLM and Agentic Top 10

PDF and JSON evidence export for the information-systems audit file

How this sits next to the BDDK obligation

BDDK's framework requires periodic penetration testing and managed technology risk; it does not name AI-specific tooling, and this page does not claim it does. What continuous AI-layer testing provides is the evidence a bank's information-systems audit increasingly asks about once LLM features ship: proof that the new surface is tested on a schedule, in the language customers actually use, with findings tracked to closure. Banks subject to the EU AI Act for EU-market systems get the same findings mapped to those articles at no extra step.

Frequently asked

Does BDDK require AI-specific security testing?

BDDK's information-systems regulation requires periodic penetration testing and technology risk management in general terms; it does not name AI or LLM systems. The practical question a bank faces is whether its existing test scope covers the LLM features it has shipped - typically it does not, and the AI layer needs its own recurring coverage.

Can the testing run without customer data leaving the bank?

Yes. The runtime gateway is self-hosted inside the bank network and only allow/block decisions plus redacted finding metadata flow out. Scan probes are synthetic adversarial inputs, not customer data, and target endpoints the bank registers explicitly.

How does this relate to the KVKK obligation?

Same testing, second obligation: when the LLM feature processes personal data, the personal-data extraction findings double as KVKK Article 12 technical-measure evidence. See the KVKK page for that reading.