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. The text is a living one — its article 23 repealed the earlier 2016 regulation, and a five-article amendment published on 4 July 2026, no. 33300, updated it again.

The scope of that amendment needs stating precisely: it covers only the heading of the fourth chapter, the second paragraph of article 13 and a newly added article 13/A, and its subject is the procedure for re-assessing diagnoses. The articles on transfer, data security and adequate measures do not appear in it — the residency regime continues through the links established in the 2019 text. On the data protection side, article 9 of Law No. 6698 was rewritten in full by Law No. 7499 of 2 March 2024 and entered into force on 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. At the level of the law, 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; that backups are named in the law itself lays the ground for the backup section below. 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, with most provisions including article 25 in force from 1 January 2021. The third link sits at the level of definitions and is easy to miss: primary and secondary systems are not defined in this regulation at all — 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 is striking in that it 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 here: the provision names no country, it points at the transfer regime. The architectural consequence is direct — the question is not which country the data sits in, but whether a transfer occurs at all.

Two provisions around that frame touch architecture as well. The second paragraph of the same article requires a protocol for transfers to public institutions, covering general principles, data security provisions and which data will be transferred, with the transfer carried out over KamuNET where the technical infrastructure allows. The second paragraph of article 5 states that the Ministry and its affiliated bodies will establish the necessary registration and notification system, and that country-wide information systems may be set up. An organization’s own deployment does not stand alone; it 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. That is a geography rule outright. It makes no reference to the transfer regime and carries no flexibility component such as consent or permission; across the article’s five paragraphs there is no route via Board permission, authority approval or exemption.

The real finding comes next: 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. In neither does the question begin as “which country is the data in” — the country is the subject of a second question, one that only arises after the first has been answered.

Where model inference lands as a processing step

Model inference is not a defined concept in the regulation. The mapping here is an architectural reading, not a provision. In practice inference 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, limited to the appointment day for the physician with whom the appointment is made, twenty-four hours for physicians at the health service provider, and until discharge for an inpatient. The architectural counterpart is this: which record may enter the context window, and for how long, has to be defined in the system. That is an access policy question and it is enforced in the retrieval layer — how permissions travel into the index is covered in 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, and for enumerated purposes. The architectural consequence is that the side on which the component running inference sits has to be defined. On the banking side, the three-part test from the previous section applies directly here: 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 yield two architectural outputs: where the same result can be reached without processing personal data, anonymization methods are to be preferred; and the controller or processor status of each party is to be determined at the start of the project. The same document calls for stricter measures in work involving sensitive data. In a deployment inside the organization’s own facility, most of these questions close with a single architectural decision: the data never leaves the organization’s own servers.

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 by health service providers in de-identified form is matched with the individuals it belongs to through a relational database. In other words the record can be re-matched, and the paragraph limits that authority by number — each unit head may request authorization for at most three people from their own unit. Article 16 puts scientific work with anonymized data under a separate regime.

The mapping follows. 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 re-matching authority is limited by number has a clear system counterpart too — access to the mapping table between index and source record is kept narrow and enumerated. The same reading applies to caches and intermediate outputs; they are treated in the same class as the source record.

The 2026 amendment adds a direct question to this discussion. 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 has to answer 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, along with the examples the guide gives for it — creating an account, granting access rights to an existing account, approving a remote access request, sending a password for a file.

The guide assesses two things within the same scope: a provider connecting remotely for support, troubleshooting or administration, 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 architectural counterpart is immediate: the same test applies to the telemetry channel, to licence validation traffic and to the model update channel. A design in which those channels are closed by default and opened one at a time costs less than an assessment made after the fact. 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. The same regulation also keeps data concerning health and sexual life outside the exemption cases even where it constitutes customer secrecy, uniting both strands of this note in a single provision.

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; it may cover a country, sectors within a country, or international organizations. Where there is none, one of four appropriate safeguards applies — an agreement between public institutions with Board permission, binding corporate rules, the standard contract published by the Board, or a written undertaking with Board permission. Failing those, a transfer is possible only on an incidental basis. The paperwork carries architectural cost too: 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 that principle is written into the text itself, and it closes the argument about copy counts. 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.

There is a record-keeping obligation too: the bank must record the media and locations in which backups are held, in a way that reflects the current state. On the secondary centre side, data and system backups are kept ready for use, and it is a principle that the secondary centre should not be exposed to the same geographic effects as the primary — geographic separation is required, but that separation 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, with testing over the secondary centre at least once a year and external service providers, where any exist, included in those tests. When a model version is updated at the primary centre, the copy at the secondary centre has to enter 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, cryptographic encryption on portable media with the key held separately, and encrypted corporate mail or registered electronic mail for e-mail. That the key does not travel with the copy is the most concrete architectural rule here. Derived records should not be overlooked either: the vector index, the embedding records and the cache all sit inside the backup scope.

Reading three deployment models against the same criteria

There are three models: a deployment calling a service abroad over an API, a managed deployment hosted inside the country, and on-premises AI server systems in the organization’s own facility. All three can be read with the same five questions.

• Does a transfer occur — applying the guide’s three tests, the answer can change even where the data is only displayed on screen.
• Is there a remote access channel — support, troubleshooting and administration channels are assessed within transfer scope.
• Where do onward transfers go — article 9 of Law No. 6698 requires the same safeguards for onward transfers and transfers to international organizations; responsibility runs to the end of the chain.
• Which safeguard document and notification is required — under binding corporate rules a transfer may only begin after Board approval, and the minimum content is enumerated in thirteen items.
• Where do the keys and the transaction logs sit — holding cryptographic keys in a separate environment and logging all activity is a condition independent of where the model runs.

Banking adds four more axes, all about the chain. Where outsourcing or cloud services are obtained for an activity within primary or secondary system scope, the information systems the provider uses for that service, and their backups, are also treated within that scope — the obligation does not stop at the bank’s own data centre. On the cloud side, services may be obtained through a private cloud model over resources dedicated to a single bank, while the community cloud model is subject to Board permission. Critical services cannot be obtained through standard contract models whose terms cannot be enforced, which rules out click-to-accept procurement. In provider selection, having an intervention team in Türkiye is a requirement.

The rule that a processor acts in line with the controller’s instructions has an architectural counterpart: the instruction has to be technically enforceable. Telling a provider to keep certain data in a certain region only means something if the system can make that distinction. A deployment in the organization’s own facility closes the question at the earliest point: where no transfer occurs, the three-tier safeguard structure never engages.

A placement map by institution type, and a checklist

The discussion becomes concrete once the placement map is built component by component. Model weights, the inference process, the vector index and embedding records, the cache, transaction logs, the key store, backup copies, and the administration and support channel — each of those nine items carries a question that has to be answered separately.

On institution type, three lines suffice. For banks the residency condition in article 25 applies, and that regulation covers only the banks defined in article 3 of Law No. 5411. For capital markets institutions the Communiqué on Principles Regarding Information Systems Management (VII-128.10), and for insurance and private pensions the Regulation on Internal Systems in the Insurance and Private Pension Sectors, carry a condition of similar shape. For health service providers the condition is instead established through the transfer regime.

One distinction is worth keeping in writing: the adequate measures required for sensitive data and the appropriate safeguards required for transfers abroad are not the same thing. The first arises from the class of the data, the second from where the data is going.

The checklist rests directly on the Board decision: holding sensitive data by cryptographic methods, keeping keys securely and in separate environments, logging all activity securely, at least two-factor authentication for remote access, and following security updates with regular tests. Banking adds three lines: documenting, as two separate lists, the assets that are and are not included in the secondary centre; recording each information asset’s location and security class in the inventory and reviewing those classes at intervals not exceeding two years; and keeping information systems internal control and internal audit out of scope for outsourcing.

One more note: the same residency question comes up on the tax side as well, and there the provision states geography outright. Its counterpart in the e-document world is covered in the note “Turkish e-documents: direct integration or a special integrator?”.

This note cites the regulations as written; it does not constitute legal advice. Because these texts change — the health regulation was amended in 2026, the transfer regime was rewritten in 2024 — check the current text on resmigazete.gov.tr, mevzuat.gov.tr and kvkk.gov.tr before planning.

Sources

• Regulation on Personal Health Data — Ministry of Health, Official Gazette 21 June 2019, no. 30808 (access limits art. 6, de-identification art. 7, transfer art. 15, anonymization art. 16)
• Regulation Amending the Regulation on Personal Health Data — Official Gazette 4 July 2026, no. 33300 (fourth chapter heading, art. 13/2 and new art. 13/A)
• Personal Data Protection Law No. 6698 — art. 6 on sensitive data and 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 (binding corporate rules arts. 12-13, standard contract art. 14)
• Guide on the Transfer of Personal Data Abroad — Personal Data Protection Authority, Publication No. 48, January 2025 (the three tests for a transfer, remote access counting as a transfer)
• Recommendations on the Protection of Personal Data in the Field of Artificial Intelligence — Personal Data Protection Authority, Publication No. 76, April 2025 (preference for anonymization, determining party status, privacy impact assessment)
• Personal Data Protection Board Decision No. 2018/10 of 31 January 2018 (cryptographic storage, keys in separate environments, transfer channels)
• Regulation on Banks’ Information Systems and Electronic Banking Services — BDDK, Official Gazette 15 March 2020, no. 31069 (residency art. 25, inventory art. 6, backups art. 27, secondary centre art. 28, outsourcing and cloud art. 29)
• Regulation on Banks’ Internal Systems and Internal Capital Adequacy Assessment Process — BDDK, Official Gazette 11 July 2014, no. 29057 (definitions of primary and secondary systems, 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, health data kept outside sharing)
• 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