AI APIs in Financial Services: KVKK, Data Boundaries, and Masking (Banks, Insurers, Fintechs)

Banks, insurers, and fintechs can use LLMs safely today; the condition is drawing data boundaries first: personal data is masked before a request ever reaches the model, the contracting party is chosen inside Türkiye, and cost and access controls are enforced technically. Onysoft AI Gateway ships all three — one OpenAI-compatible API, a local counterparty under Turkish law, and a budget check that runs before a request even leaves for the provider.

Finance is one of the sectors extracting value from AI the fastest — and the one with the highest data sensitivity. The two do not have to conflict: in the right architecture, the model does the heavy lifting without ever seeing personal data. In the wrong one, a single national ID number written into a request body can turn into a months-long compliance debate.

This article covers where LLMs genuinely produce value inside financial institutions, which data may go to a model, a worked example of the masking pattern, and an honest answer to the "on-prem or API?" question. We covered the general KVKK framework in depth in our KVKK-compliant AI guide; the focus here is finance practice.

Where Do LLMs Produce Real Value in Financial Services?

The three areas where LLMs prove themselves fastest inside financial institutions are document analysis, customer communication, and compliance/regulation summaries. What the three share: most of the work is reading, understanding, and summarizing text — and the final decision stays with a human.

• Document analysis: Loan files, appraisal reports, insurance claim files, contracts. The model extracts a structured summary from a file hundreds of pages long; the analyst makes the final call. Long-context models can process the entire file in a single request.
• Customer communication: Complaint and request classification, support reply drafts, call summaries. High-volume and repetitive, so this is where automation pays back fastest.
• Compliance and regulation summaries: Pre-screening the impact of regulatory changes on internal procedures, internal audit finding summaries, policy document comparison. Most of the input is public or corporate text, so the personal-data load is naturally low.

The critical framing for decision-makers: in none of these scenarios does the model decide — it prepares the decision. Defining the scope as "work that produces no outcome without human sign-off" shrinks both the risk and the internal approval process; picking your pilot from this class is the shortest path to production without stalling on the compliance side.

Data Boundaries: Which Data May Go to a Model, and How Does Masking Work?

The rule is simple: the model receives the minimum data the task requires; identifying fields — full name, national ID (TCKN), IBAN, phone, card number, customer number — are masked on the application side before they ever enter the request body. The model does not need to know who the customer is in order to categorize a complaint.

In practice the masking pattern has three steps: (1) replace sensitive fields with tags before the request, (2) send the masked text to the model, (3) re-substitute the tags inside your own system after the response returns, if needed. The mapping table (which tag corresponds to which real value) never leaves the institution:

# Before the request leaves (raw text inside the institution):
"Customer Ayse Yilmaz (TCKN 12345678901) is asking about the status
of the transfer from account TR33 0006 1005 1978 6457 8413 26..."

# Masked version (the only thing the model sees):
"Customer {NAME_1} (TCKN {TCKN_1}) is asking about the status
of the transfer from account {IBAN_1}..."

Boundary approaches by scenario:

Scenario	What is in the raw data?	What goes to the model?	Boundary approach
Complaint/request classification	Free text with names, TCKN, IBAN	Masked text	Pre-request masking
Loan/claim file summary	Contracts, appraisals, identity data	De-identified document	Masking + field extraction
Regulation/compliance summary	Public regulation, internal procedures	The text itself	Data classification check
Customer reply draft	Masked context + template	Masked context	Re-substitution on output

An honest note: regex-based masking (for deterministic formats such as TCKN, IBAN, and phone numbers) is a good start, but free-text fields such as names and addresses need an NER (entity recognition) layer and a central masking dictionary in production. Put masking quality under test coverage too — the boundary is drawn in code.

The KVKK Counterparty Question and Regulatory Sensitivity

From a KVKK standpoint the first question is not technical but contractual: who is your counterparty in the data-processing chain, and under which law? Working directly with a provider abroad triggers cross-border transfer provisions; working with a gateway established in Türkiye lets you sign a data-processing agreement under Turkish law and name a concrete counterparty in your privacy notice. On Onysoft the contracting party is Onysoft Veri Merkezi A.Ş., established in İzmir; the full conceptual framework — processor/controller relationship, notice obligations, retention periods — is covered in detail in the KVKK-compliant AI guide, so we do not repeat it here.

For financial institutions the picture goes one layer deeper: banks, payment institutions, and insurers are subject to their own sectoral regulations on top of KVKK — outsourcing, information systems, and customer-confidentiality obligations chief among them. How those rules apply to a specific AI architecture depends on the institution type, the nature of the data, and the workflow; a blanket "compliant / not compliant" verdict here would not be honest. The right order is: settle the data-boundary architecture first (previous section), then have that architecture assessed by your compliance and legal teams under your own regulatory framework.

Masking is not merely a technical measure here — it is also the strongest page in your compliance file: being able to prove the sentence "no personal data reaches the model" narrows the scope of notice and transfer debates from the outset.

This article is not legal or financial advice; consult your legal, compliance, and tax advisors before implementation.

On-Prem or API + Masking? An Honest Analysis

In most finance scenarios API + masking is sufficient; on-prem deployment is the answer for the narrow set of scenarios where raw data must never leave the institution in any form. The choice should be made per scenario, not ideologically.

When API + masking is enough:

• The task operates on masked or personal-data-free text (classification, summarization, draft generation — i.e., most of the scenarios in the previous sections).
• You need flagship-class model quality: the strongest models are delivered via API, and the gap versus open-weight models is most noticeable in reasoning-heavy analysis.
• The team lacks GPU infrastructure and MLOps muscle: the hidden cost of on-prem is not the hardware but the continuity — model updates, security patching, scaling, and the people to do it.
• You need to reach production fast: on the API side the first request goes out within minutes.

When on-prem (or self-hosting in your own cloud) is the right answer:

• Internal policy or regulatory interpretation categorically forbids raw data from crossing the institutional boundary, and masking does not change that interpretation.
• A physically isolated (air-gapped) environment is required.
• Full control over model weights and version-pinned model behavior is critical.

In practice the healthiest setup for most institutions is hybrid: a small in-house model for one narrow, sensitive flow, and the API behind a masking layer for the remaining high-volume work. The on-prem investment is made only for the flow that truly requires it, while overall productivity draws on flagship model quality.

How It Works on Onysoft: Controls and Setup for Finance Teams

Onysoft AI Gateway ships the first two things finance teams ask any provider about — budget control and audit trail — as product mechanics; both are on without any configuration.

• Surprise bills are technically impossible: Every request passes a balance pre-check before it goes to the provider — the estimated cost is computed with a 1.2 buffer, and if the balance is insufficient the request returns a 402 without ever leaving. When the balance runs out the system stops automatically; there is no going negative, no end-of-period surprise, no open-ended subscription risk. For finance projects with pre-approved budgets, the "spending cap" clause is satisfied by construction.
• Per-key permissions and limits: A separate API key per application, team, or project; model restrictions and token limits are defined per key. The complaint-classification service can be limited to the economy model while the analytics team's key has flagship access.
• Audit trail: Every response returns the real cost (the cost field, in USD); the panel shows the TRY equivalent. Usage reports are filterable by date/model/status, downloadable as PDF, or sent to internal stakeholders as a logo-branded email report — for internal audit, the answer to "which request, which model, what cost" is a ready-made file.
• Corporate invoicing: Enter your tax number (VKN) in the billing details and the "Query GİB" button checks the registry live; if you are a registered taxpayer the company title auto-fills and an e-Fatura is issued, otherwise an e-Arşiv invoice — in TRY. The withholding/reverse-charge VAT obligations that arise with foreign AI subscriptions do not arise on a domestic invoice (consult your tax advisor).

On the developer side, setup together with the masking layer is a few lines thanks to the OpenAI-compatible endpoint:

import re
from openai import OpenAI

client = OpenAI(
    base_url="https://api.onysoft.com/v1",
    api_key="sk-ony-YOUR_KEY",
)

MASKS = [
    (re.compile(r"TR\d{2}[\d ]{22,30}"), "{IBAN}"),
    (re.compile(r"\b\d{11}\b"), "{TCKN}"),
    (re.compile(r"\b0?5\d{2}[\s-]?\d{3}[\s-]?\d{4}\b"), "{PHONE}"),
]

def mask(text: str) -> str:
    for pattern, tag in MASKS:
        text = pattern.sub(tag, text)
    return text

response = client.chat.completions.create(
    model="anthropic/claude-sonnet-5",
    messages=[{
        "role": "user",
        "content": "Categorize this complaint and summarize it in two sentences:\n"
                   + mask(complaint_text),
    }],
)
print(response.choices[0].message.content)

On response times, let us talk measurement rather than estimates — from our own production traffic:

Metric (last 14 days)	Value
Successful requests	6,959
Average end-to-end response time	3.8 seconds
Fastest response	0.3 seconds

Measured: August 5, 2026 — api.onysoft.com live catalog.

To get started: open an account, verify your VKN with the live GİB query in billing details, generate a key per project and define model/token limits, wire up your masking layer, and try the first request without writing code in the Playground. The catalog offers 739+ models from more than 60 providers under one key; for the broader picture, the AI API guide is a good next stop.

Last updated: August 5, 2026 · Data: api.onysoft.com live catalog