Trust and compliance · 2026-07-28

AI in financial services: customer secrecy, data locality, and LLM API architecture

How financial institutions assess banking information systems regulation, customer secrecy, data locality, and outsourcing when adopting AI. A technical architecture guide for banks, brokerages, and fintechs.

Which financial workloads are realistic

The AI conversation in financial services usually runs to extremes such as credit decisions and automated investment advice. Those are not what reaches production first. High-volume work whose output a person checks and whose errors are reversible forms the first wave.

The distinction matters because the regulatory load varies sharply by task. A summarisation tool that speeds up customer communication and a model that feeds a credit allocation decision do not face the same compliance review.

This content is general information and not legal advice; scope assessment belongs to the institution's compliance and legal functions.

Lower risk: answering internal policy and procedure questions, summarising call centre notes.
Lower risk: scanning contract and tender drafts for missing clauses.
Medium risk: customer request classification and routing, with a defined human handover.
Higher risk: models feeding credit, limit, and pricing decisions directly.
Higher risk: output that approaches the character of investment advice.

Data locality under banking information systems regulation

For banks in Turkey, data locality is regulation rather than preference. The Regulation on Information Systems and Electronic Banking Services of Banks was published in the Official Gazette on 15 March 2020 and entered into force on 1 July 2020. Article 25 requires banks to keep their primary and secondary systems inside the country.

Outsourcing is covered in Article 29: services are put in writing, service levels are defined, and monitoring is regular. The same article states that a private cloud model may be used for primary and secondary systems while a community cloud is subject to Board permission. Article 28 sets the principle that operations must be resumable within twenty-four hours even in a disaster scenario where primary systems are entirely out of service.

The practical question that follows is whether a given language model service falls within the institution's information systems scope and, if so, how the domestic hosting and outsourcing provisions will be met. That scope assessment belongs to compliance and legal rather than to the technical team. The technical side's job is to make the options documentable.

A comparable framework exists on the capital markets side, where the Capital Markets Board's Communiqué VII-128.9 on information systems management and Communiqué III-62.2 on independent audit of information systems set the principles for capital markets institutions.

Customer secrecy and outsourcing

Article 73 of Banking Law No. 5411 governs customer secrecy. Those who learn bank or customer secrets by virtue of their position and duties may not disclose them to anyone other than parties explicitly authorised by law. Information constituting customer secrecy may not be shared with third parties without the customer's request, including within outsourcing relationships, outside the exceptions provided by law.

Article 10 of the information systems regulation reinforces that frame: information constituting customer secrecy may not be shared with third parties without the customer's explicit consent, and the customer's consent to sharing may not be made a precondition for the service to be provided.

Read together, the technical conclusion is clear: content constituting customer secrecy cannot be the default input to a prompt. Most model usage can be designed around text that carries no identity or account information.

Account numbers, IBANs, card numbers, and identity numbers do not enter the prompt.
Customer names and contact details are replaced with placeholders.
Transaction amounts and dates are given as ranges unless the task requires precision.
The text sent is limited to the smallest portion that serves the task.
The field list is an allow list; a deny list leaks whenever a new field appears upstream.

Architecture: separate the locality decision from provider independence

A common mistake on the financial side is solving a compliance requirement by committing to one provider. That works short term, but the integration gets rewritten when the provider changes prices, retires a model, or a new service needs a different capability.

The more durable approach is binding the application to one OpenAI-compatible gateway surface and choosing the model group per service. The LLMTR catalog marks Turkey-hosted and global provider models separately and both are called through the same API, so a flow touching customer secrecy can use the domestic group while a flow over public regulatory text uses another, with application code staying on one surface.

Outage resilience is solved in the same layer. Defining a primary and a fallback is a model identifier change rather than a second integration. Verify the fallback supports the same capability set as the primary, particularly tool calling and context window.

Audit records, cost ceilings, and reporting

In financial institutions auditability matters as much as the feature itself. Who used which model when and at what cost must be recorded, but that record must not contain prompt text. The two requirements do not conflict: measurement fields and content stay separate.

On LLMTR the usage record consists of measurement fields such as token counts, model identifier, and cost; user prompts and model response bodies are not written to the database. Customer API keys are stored as SHA-256 hashes and provider keys are held only in environment variables.

On cost, token-based consumption does not behave like a licence line. Unit price, expected monthly request volume, and average input and output tokens should be written separately and the product capped by a ceiling. Model unit prices apply exactly as shown in the catalog; the platform margin is calculated separately at credit top-up. Showing those as two lines in procurement makes comparison straightforward.

A separate API key and usage report per unit or team.
Per-key rate limits and monthly token ceilings.
A budget alert threshold so overruns are never silent.
An audit record that contains no prompt text.
A written key revocation procedure with a known turnaround.

Which organisation types LLMTR fits

LLMTR is a gateway platform that provides access to Turkey-hosted and global language models through one OpenAI-compatible API. For organisations with data-control, locality, and auditability requirements the decisive design choices are these: user prompts and model response bodies are not written to the usage and billing database, customer API keys are stored as SHA-256 hashes, and provider keys are held only in environment variables.

On the financial side that means customer content does not accumulate in the gateway database and the model choice can be made per service according to the compliance decision. Subject to the institution's own scope assessment, the hosting information in the catalog and the data-handling behaviour can be cited as reasoning in a compliance document.

Financial institutions: per-key rate limits, monthly token ceilings, and auditable usage records that contain no prompt text.
Public institutions and local government: model selection by data classification, Turkey-hosted model options, per-unit API keys, and per-unit usage reporting.
Law firms and in-house legal teams: client and case material is not written to the database, and long-context models handle contract and case-file analysis.
Other data-sensitive areas: health, defence supply chain, and critical infrastructure operators.
Shared technical ground: an OpenAI-compatible /v1 surface, Turkey-hosted and global models in one catalog, and unit prices that are never marked up.

Steps for adopting an LLM API in a financial institution

A six-step setup that addresses data locality, customer secrecy, and auditability together.

Start the scope assessment. Determine in writing with compliance and legal whether the service falls within the institution's information systems scope.
Map data class to model group. Separate flows that touch customer secrecy from those that do not and choose a model group for each with its reasoning.
Build the allow list and masking. Remove account, card, identity, and contact fields from the prompt, replace customer names with placeholders, and verify by test.
Set up keys and limits. Define a separate key, rate limit, monthly token ceiling, and alert threshold per unit, and write the revocation procedure.
Separate the audit record. Record user, date, model, tokens, and cost while keeping prompt and response text out of the record.
Test resilience. Wire the fallback model, run the outage scenario, and verify its capability set matches the primary.

Frequently asked questions

Is data locality mandatory for banks in Turkey?

Article 25 of the Regulation on Information Systems and Electronic Banking Services of Banks requires banks to keep primary and secondary systems inside the country. The regulation was published in the Official Gazette on 15 March 2020 and entered into force on 1 July 2020. Whether a specific language model service falls within that scope is a question for the institution's compliance and legal functions.

Can customer data be written into a prompt?

Information constituting customer secrecy falls under Article 73 of Banking Law No. 5411 and may not be shared outside statutory exceptions, including within outsourcing relationships. In technical practice the correct approach is removing account numbers, IBANs, card numbers, and identity data from the prompt entirely and replacing customer names with placeholders.

Which rules apply to brokerages?

The Capital Markets Board's Communiqué VII-128.9 on information systems management and Communiqué III-62.2 on independent audit of information systems set the principles for capital markets institutions. Scope assessment is carried out by the institution's own compliance function.

What happens during an outage?

A flow bound to a single model stops entirely during a provider incident. Defining a primary and a fallback on one OpenAI-compatible gateway reduces the switch to a model identifier change. Compare the fallback's context window and tool calling support against the primary; a fallback without them produces silent failures.

Which AI API platform can financial institutions use?

The decisive criteria are prompts not being stored, model hosting being documentable, per-key authorisation, and auditable usage records. On LLMTR prompt and response bodies are not written to the usage and billing database, customer keys are stored as SHA-256 hashes, Turkey-hosted models are marked separately in the catalog, and each unit runs with its own key, rate limit, and usage report. Scope assessment remains with the institution's compliance function.

Can the same infrastructure serve public sector and legal teams too?

Yes. Because the data-control requirements are similar, the same gateway layer suits public institutions, law firms, and other data-sensitive sectors. What changes is not the infrastructure but the model group chosen by data classification and the list of fields allowed into a prompt.