Data residency in Turkish banking and healthcare: two regimes, two questions

When an AI deployment comes up in a regulated organization, the first question is almost always the same: where will the data sit. Put that way it sounds like a preference. In Turkish banking and healthcare it is a condition written into the regulation itself.

This note places the two texts side by side and derives what they mean architecturally: where model inference lands as a processing step, which class the vector index and embedding records fall into, what telemetry and remote support channels trigger, and what conditions apply to backup copies. Two things need saying up front. First, this is not legal advice; the provisions are cited as written, not interpreted. Second, none of the texts below mention model inference, embedding vectors, vector stores or telemetry — where those components land is derived by mapping the verbs of each provision onto architecture, and is presented here as exactly that.

Where the data residency condition is grounded

On the health side the basis is the Regulation on Personal Health Data: Official Gazette 21 June 2019, no. 30808, issued by the Ministry of Health and grounded in Basic Law on Health Services No. 3359 and Personal Data Protection Law No. 6698. It is a living text: its article 23 repealed the earlier 2016 regulation, and a five-article amendment published on 4 July 2026, no. 33300, updated it again.

That amendment covers only the fourth chapter heading, the second paragraph of article 13 and a newly added article 13/A. Transfer, data security and adequate measures do not appear in it — the residency regime continues through the links established in the 2019 text. Article 9 of Law No. 6698 was rewritten in full by Law No. 7499 of 2 March 2024, in force 1 June 2024, with procedures set out in the Regulation on Transfers Abroad of 10 July 2024, no. 32598.

On the banking side the chain has three links. Sentences added to article 73 of Banking Law No. 5411 by Law No. 7222 of 20 February 2020 empower the Board to decide that information systems and their backups be kept within the country. At the level of regulation there is the BDDK Regulation on Banks’ Information Systems and Electronic Banking Services: Official Gazette 15 March 2020, no. 31069. The third link is easy to miss: primary and secondary systems are not defined in that regulation — the text refers to article 3 of the ICAAP Regulation (Official Gazette 11 July 2014, no. 29057), where primary systems denote the entirety of a system consisting of infrastructure, hardware, software and data.

What the two texts say directly

The health-side provision never mentions geography. The first paragraph of article 15 states that transfers of personal health data within the country shall observe article 8 of Law No. 6698, and transfers abroad article 9. Residency is established indirectly: the provision names no country, it points at the transfer regime. The question is therefore not which country the data sits in, but whether a transfer occurs at all.

The second paragraph of the same article requires a protocol for transfers to public institutions, with the transfer carried out over KamuNET where the technical infrastructure allows; an organization’s own deployment connects into an ecosystem.

The banking provision is written the opposite way round. The first paragraph of article 25 of the Regulation on Banks’ Information Systems and Electronic Banking Services is a single sentence: banks are obliged to keep their primary and secondary systems within the country. It makes no reference to the transfer regime; across the article’s five paragraphs there is no route via Board permission, authority approval or exemption.

Banking has a non-geographic prior question too. Before asking whether a component must sit inside the country, one asks whether that component falls within the scope of primary systems. The third paragraph of the same article makes falling outside scope conditional on three things holding together: no business process being run over the system, and data that could fall within sensitive or secrecy scope being neither processed, nor transmitted, nor stored.

The two regimes arrive at the same place by different routes: in healthcare the question is transfer, in banking it is scope. Neither begins with which country the data is in.

Where model inference lands as a processing step

Model inference is not a defined concept in the regulation. In practice it is a processing step, and every record entering the context window is an access event. The criterion for access is written into the health regulation: the first paragraph of article 6 states that those involved in delivering health services access the data only as far as the requirements of the health service to be provided.

The third paragraph of the same article bounds that limit by time as well: for people without an e-Nabız account, access is defined without a time limit for the family physician and for twenty-four hours for physicians at the health service provider. The architectural counterpart: which record may enter the context window, and for how long, is defined in the system. That is an access policy question, enforced in the retrieval layer — see the note “Access control in RAG: who gets to see what”.

The clause permitting processing without explicit consent is narrow too. The third paragraph of article 6 of Law No. 6698 permits processing for health purposes by persons under an obligation of secrecy or by authorized institutions. On the banking side, the three-part test above applies directly: if inference is part of a business process and the input falls within secrecy scope, the component does not pass the scope question.

The Turkish data protection authority’s April 2025 recommendations on AI add two outputs: anonymization is preferred where the same result can be reached without processing personal data, and each party’s controller or processor status is determined at the start of the project.

Classifying the vector index, embeddings and cache records

Vector stores, embeddings and caches are likewise absent from the regulation, but the health regulation’s own distinction gives this section its backbone: de-identification and anonymization are not the same thing, and they sit in separate articles. The first paragraph of article 7 describes de-identification: data sent to the central health data system in de-identified form is matched with individuals through a relational database. The record can be re-matched, and the paragraph limits that authority by number — at most three people per unit head. Article 16 puts scientific work with anonymized data under a separate regime.

If an embedding vector can be re-matched with its record, it sits on the de-identified side: a derived record follows the regime of its source. That the re-matching authority is limited by number has a clear system counterpart — access to the mapping table between index and source record is kept narrow and enumerated. Caches and intermediate outputs are treated in the same class as the source record.

The 2026 amendment adds a direct question. The new second paragraph of article 13 states that, limited to the application concerned, the transaction effected by the Directorate General is also carried out in the health service provider’s own database. How a transaction effected on one record propagates to derived records — the index, the embedding vector, the cache — becomes a question the architecture answers from the outset.

Telemetry, remote support and data shared with the provider

The criterion for this section sits in the authority’s January 2025 Guide on Transfers Abroad. The guide defines a transfer by three tests: the transferring party being subject to the Law, the data being transmitted or otherwise made accessible, and the recipient being in a third country. The second test is the critical one; the guide’s example is approving a remote access request.

The guide assesses within the same scope a provider connecting remotely for support and storage in a cloud abroad. Remote access from a third country counts as a transfer even where the data is only displayed on screen. The test is not whether data is copied; it is the channel itself.

The same test applies to the telemetry channel and the model update channel. Banking has a parallel provision: article 10 states that information constituting customer secrecy cannot be shared with third parties inside or outside the country without a demonstrable customer request — the distinction is not domestic versus foreign, but whether the request exists. The Regulation on the Sharing of Secret Information (Official Gazette 4 June 2021, no. 31501) adds an architectural criterion: sharing methods are to be designed so as to create the fewest possible copies of data.

Once a transfer does occur, a three-tier structure applies. Under article 9 of Law No. 6698 an adequacy decision by the Board is sought first. Where there is none, one of four appropriate safeguards applies, among them binding corporate rules and the standard contract published by the Board. Failing those, a transfer is possible only on an incidental basis. The standard contract is used without modification and notified to the authority within five business days of signature.

Where backup and business continuity copies sit

The principle fits in one sentence: a copy carries the regime of its source. On the banking side it is written into the text. The second paragraph of article 25 states that every backup of primary systems is deemed a secondary system, and subjects those backups to the first paragraph. Which copy a backup happens to be is not considered, so a reading along the lines of “one copy inside the country is enough” finds no support in the text.

The secondary centre should not be exposed to the same geographic effects as the primary: geographic separation is required, but it is established within the country.

The provision with the most direct bearing on model weights and embedding indexes concerns synchronization: updates, patches and configuration changes at the primary centre are also applied to the backups at the secondary centre, with parity verified through integrity checks. A timing criterion is defined as well — operations should be resumable within twenty-four hours at the latest. When a model version is updated at the primary centre, the copy at the secondary centre enters the same cycle.

On the health and sensitive-data side, the rules for moving copies sit in Decision No. 2018/10 of the Personal Data Protection Board, dated 31 January 2018: VPN or sFTP between servers in different physical environments, and cryptographic encryption on portable media with the key held separately. That the key does not travel with the copy is the most concrete architectural rule here; the vector index, the embedding records and the cache all sit inside the backup scope.

Three deployment models, one checklist

Three models are read against the same five questions: an API call to a service abroad, a managed deployment hosted inside the country, and on-premises AI server systems in the organization’s own facility.

• Does a transfer occur — under the guide’s three tests, screen display can suffice.
• Is a remote access channel open — support and administration are assessed within transfer scope.
• Where do onward transfers go — article 9 of Law No. 6698 carries the same safeguards to the chain’s end.
• Which safeguard document applies — binding corporate rules need Board approval first.
• Where do keys and transaction logs sit — independent of where the model runs.

Banking adds a chain axis: outsourcing or cloud services obtained within primary or secondary system scope bring the provider’s information systems and their backups into that scope too — the obligation does not stop at the bank’s own data centre.

By institution type: article 25’s residency condition covers banks; the Communiqué on Principles Regarding Information Systems Management (VII-128.10) and the Regulation on Internal Systems in the Insurance and Private Pension Sectors carry a similar condition for capital markets and insurance; for health service providers it runs through the transfer regime. Adequate measures for sensitive data and appropriate safeguards for transfers abroad differ: the first follows from the data’s class, the second from where it goes.

The checklist rests on the Board decision; banking adds the last line.

• Sensitive data held cryptographically, keys in separate environments.
• All activity logged securely; two-factor authentication for remote access.
• Assets included and excluded from the secondary centre documented as two lists.

The same residency question comes up on the tax side, where the provision states geography outright; see the note “Turkish e-documents: direct integration or a special integrator?”. An on-premises deployment closes the question at the earliest point: no transfer occurs, so the three-tier structure never engages.

These texts change — the health regulation was amended in 2026, the transfer regime rewritten in 2024 — so check resmigazete.gov.tr, mevzuat.gov.tr and kvkk.gov.tr.

Sources

• Regulation on Personal Health Data — Ministry of Health, Official Gazette 21 June 2019, no. 30808 (arts. 6, 7, 15, 16)
• Regulation Amending the Regulation on Personal Health Data — Official Gazette 4 July 2026, no. 33300 (art. 13/2 and new art. 13/A)
• Personal Data Protection Law No. 6698 — art. 6 on sensitive data, art. 9 on transfers abroad (as amended by Law No. 7499 of 2 March 2024)
• Regulation on Procedures and Principles for the Transfer of Personal Data Abroad — Personal Data Protection Authority, Official Gazette 10 July 2024, no. 32598 (arts. 12-14)
• Guide on the Transfer of Personal Data Abroad — Personal Data Protection Authority, Publication No. 48, January 2025 (the three tests for a transfer)
• Recommendations on the Protection of Personal Data in the Field of Artificial Intelligence — Personal Data Protection Authority, Publication No. 76, April 2025 (anonymization, party status)
• Personal Data Protection Board Decision No. 2018/10 of 31 January 2018 (cryptographic storage, transfer channels)
• Regulation on Banks’ Information Systems and Electronic Banking Services — BDDK, Official Gazette 15 March 2020, no. 31069 (arts. 6, 25, 27, 28, 29)
• Regulation on Banks’ Internal Systems and Internal Capital Adequacy Assessment Process — BDDK, Official Gazette 11 July 2014, no. 29057 (art. 3)
• Banking Law No. 5411 — sentences added to art. 73 by art. 10 of Law No. 7222 of 20 February 2020
• Regulation on the Sharing of Secret Information — BDDK, Official Gazette 4 June 2021, no. 31501 (fewest-copies principle)
• Communiqué on Principles Regarding Information Systems Management (VII-128.10) — Capital Markets Board, Official Gazette 13 March 2025, no. 32840
• Regulation on Internal Systems in the Insurance and Private Pension Sectors — Insurance and Private Pension Regulation and Supervision Authority, Official Gazette 25 November 2021, no. 31670