AI in Fintech and Banking: Türkiye’s KVKK, Data Privacy and User Rights

The information a financial assistant needs is a product design question from the beginning. A feature that summarises account activity and an assistant that explains general product terms do not require the same data. That distinction should be reflected in the system and in the experience customers see.

AI and data protection cannot be addressed solely by attaching a privacy notice at the end of a project. Data purposes, explanations, choices and request pathways need to be considered within the product journey. This article uses official Turkish sources to explore design implications. It does not provide a legal compliance opinion for a specific implementation.

Start with the relevant Turkish framework

The Turkish Personal Data Protection Authority’s generative AI guide addresses personal data processing across the AI lifecycle. The Authority and the Banks Association of Türkiye also updated their banking good practice guide to reflect the 2024 legislative changes. These resources should be read alongside the applicable legislation.

For product teams, “we use AI” is too broad a description. Which feature processes which information, for whose benefit and for what purpose? Who sees the output? Is an external provider involved? Interface copy written before these questions are answered may fail to describe the actual service.

Türkiye is the jurisdiction discussed here. The article should not be read as a description of GDPR requirements or as a universal framework for every market.

Design data flows alongside user journeys

Consider a proposed monthly account summary. The customer selects a period, the service processes relevant records and an explanation appears. Behind that simple interaction may sit source transactions, model inputs, generated content and operational logs.

The design process should make the purpose and visibility of these layers explicit. If a task does not need full transaction descriptions, the team can investigate whether a narrower input is sufficient. Asking customers to select an account creates a different scope from including every account automatically. These are design options whose technical feasibility and legal basis require separate assessment.

A visually simple screen does not imply a simple data flow. If the interface says that only the selected account is included, the underlying service must match that description. Information architecture and data mapping therefore need to inform each other.

Separate privacy information from consent

The Authority’s communiqué on the duty to inform distinguishes providing information from obtaining consent when processing relies on consent. The duty to inform also applies under other processing conditions. Teams should not assume that every AI feature necessarily relies on explicit consent; the relevant basis must be established for the activity.

In interface terms, a link that explains data use and a control that records a particular choice perform different jobs. A broad statement that continuing means accepting everything does little to clarify the action a customer is taking.

A layered approach can provide a concise, contextual explanation with easy access to the full notice. The short explanation should support rather than replace the complete information. Testing should examine what people understand, rather than merely whether a notice was displayed.

Distinguish service delivery from model development

A customer asking a question has not necessarily understood every possible subsequent use of the conversation. Providing the service, reviewing quality and developing a model can involve different purposes. Teams should identify and assess them separately.

If a feature accesses account activity only to answer the current question, the interface should reflect that scope. If information also enters other processes, a narrowly worded explanation should not obscure them. Supplier terms, technical configuration and customer-facing descriptions need to be consistent.

Controls require the same precision. Disabling future personalisation may not remove historical records. A switch should not be labelled as deleting data if that is not what it does. Users need to understand the effect and limits of their choices.

Make rights accessible in automated decision journeys

The Authority’s summary of Article 11 rights includes requesting correction of inaccurate or incomplete data and objecting to an adverse result arising solely from automated analysis. Whether a particular process falls within that provision requires assessment; not every AI recommendation is automatically equivalent.

From a product perspective, a request pathway can do more than display an email address. A customer could identify the relevant decision, describe the disputed information and receive confirmation that the request was submitted. Status tracking is a design option intended to reduce uncertainty, rather than a claim that the law mandates a particular screen.

For a lending journey, explanations should be limited to reasons the organisation can substantiate. Generating a convincing explanation that does not reflect the actual assessment would undermine the purpose of transparency. Requesting review should also be clearly distinguished from starting a new application.

Use precise language for history, deletion and retention

Removing a conversation from the interface is not necessarily the same as deleting every related record across every system. “Clear chat history” and “Submit a personal data request” may initiate different operations. The product needs to explain which one is happening.

Teams should understand applicable retention requirements and operational constraints before writing definitive deletion promises. Withdrawing a preference should not be presented as automatically reversing every previous processing outcome. Accurate microcopy follows an understanding of the underlying process.

This is particularly important when different teams own the conversation interface, support platform and analytics environment. A label in one part of the product should not promise an effect that other systems cannot deliver.

Test whether people can exercise control

Research tasks can ask participants to identify which accounts a feature uses, change a personalisation preference or submit a correction request. Observing completion is useful, but the participant should also be able to explain what they believe changed.

Include differences in financial literacy, digital confidence and accessibility needs. Legal accuracy and comprehensibility are distinct quality criteria. A notice may be accurate while the route to making a request remains difficult to use.

Design reviews should also examine failure states. If a request cannot be submitted, the interface should not imply success. If additional information is necessary, the reason and next step should be clear. Rights-related journeys deserve the same interaction quality as acquisition and sales journeys.

VOYA’s role in privacy-conscious product design

VOYA helps translate requirements established with legal and compliance teams into understandable product journeys, information architecture and prototypes. Design does not replace legal assessment. It helps make agreed requirements visible and usable within the service.

In AI product transformation, data use, customer control and operational behaviour should be considered together. For the broader trust perspective, read AI in banking and customer trust; for support workflows, see AI assistants in banking.

Frequently asked questions

Does every AI feature require explicit consent under KVKK?

The answer depends on the applicable processing basis. Using AI does not by itself establish either a consent requirement or an exemption.

Is a privacy notice enough to create a usable experience?

Customers also need clear controls, accurate action labels and accessible request pathways. These design recommendations are not a complete legal compliance checklist.

Does deleting a chat erase all related data?

That depends on the implementation and applicable requirements. The interface should distinguish clearing visible history from submitting a data deletion request and explain the actual scope.