KVKK Information Notice (Aydınlatma Metni)

1. What this notice does and does not do

This notice exists to satisfy the disclosure duty in Article 10 of Law No. 6698 on the Protection of Personal Data (“KVKK”). It has one purpose: to tell you which of your personal data is processed, for what purpose, on what legal basis, and to whom it is transferred.

• This is information. It is not a contract you accept and it is not a consent box.
• There is no “I accept the KVKK Notice” box on the site, and there will not be one. Disclosure and explicit consent are separate acts. Article 5/1-f of the Communiqué on the Procedures and Principles to be Followed in Fulfilling the Disclosure Obligation expressly requires them to be carried out separately. The previous version of this notice fused the two; that sentence has been removed.
• There are two places where explicit consent is genuinely taken, and both sit outside this notice: the “Show on TradingView” button in the VIX box on the US equities page, and the newsletter tick during sign-up. Both are described in section 5.
• New account creation is currently closed: sign-up requests are refused at the authentication provider level, so no new account can be created today. When sign-up opens, this notice applies exactly as written.

2. The personal data processed

The list below is what the system actually holds.

• Identity and contact. Your email address. There are three ways to sign in: a one-time link sent to your email, “Continue with Google”, or email and password. If you choose a password, it travels from your browser directly to our authentication infrastructure over TLS and is stored there only as a one-way hash; the password itself never reaches our servers and we cannot see it. If you choose Google, the account identifier, email address and general profile information (your name, the address of your profile picture) that Google passes during authentication are stored in our authentication infrastructure.
• Account and preference data. Your display name, your plan (Ücretsiz, Mergen, Pro), your credit balance, your language and theme preference, your newsletter preference.
• Portfolio tracker records. The transaction records and notes you type into the portfolio section yourself. They are your own statement; we do not verify whether they correspond to real holdings, and we connect to no bank, exchange or wallet account of yours.
• Credit system records. The in-account records of how your credit balance was earned and how it was spent.
• Launch-notification list. The email address you left in order to be told about the launch announcement, the language you were reading the page in, and — if you arrived by an invite link — that invite’s code. This record is independent of your account: someone with no account can join the list, and the record is not tied to a user id. How long it is kept, and how you can have it deleted, are in section 8.
• Pro early-access request. If you press “Request early access” on the plans page, your email address, the language you were reading, the time of the request and — if you were signed in — your account id are written to a list on our server and notified to info@mergen.finance. Payments are not open yet, so Pro is turned on by hand from that list.
• Access request (“Request access”). If you press “Request access” on a plan box for Mergen or Pro, your email address, the plan you asked for, the language you were reading, the time of the request, which section’s box it came from, its status (new, granted, declined) and — if you were signed in — your account id are written to a table in our database. The purpose is to handle your request (KVKK art. 5/2-c). It is kept until the request is settled, then for 12 months, and deleted by the nightly job.
• Plan box measurement. When a plan box appears on screen or is clicked, only this is recorded: which section it is in, which plan it presents, the reader’s plan level (anonymous, Free, Mergen, Pro), the theme and the screen class (phone, tablet, desktop). No account id, email or IP address is recorded; no person can be reached from these records. The purpose is to measure which sections are useful (KVKK art. 5/2-f). Single records are kept for 90 days, then turned into daily totals and deleted.
• Technical records. Our server access logs record your IP address, your browser information and the address of the page you requested. They are kept for the security of the service and to prevent abuse.
• Cookies and browser storage. The full list lives in one place: the Cookie Policy. This notice does not repeat that table. The reason is simple: the cookie list is derived from the code itself and changes when the code changes, and a list kept in two places eventually becomes two different lists.
• What we do not process. We do not take or store payment or card details — there is no payment step on the site yet (see section 4). We do not ask you for special categories of personal data (such as health, belief or biometric data); no such field exists. We use no ad network, no pixel, no tag manager and no separate analytics provider. We do not sell your personal data and we do not share it with third parties for marketing.

3. Who processes this data — the data controller

The data controller under the KVKK is Mergen Finance, which operates the mergen.finance website. The data controller’s identity and the address for applications are given in the last section of this notice (section 12).

In that capacity, your personal data is processed for the purposes listed below, each on the legal basis shown separately for it. You can send questions about this notice and applications under Article 11 of the KVKK in the way described in section 9.

4. Purposes of processing and the legal basis for each

Each line is one purpose and the legal basis it rests on. No purpose is given more than one basis; every processing operation sits on a single ground.

• Creating your membership, signing you in and managing your account — performance of a contract (KVKK art. 5/2-c). Sending the sign-in link is included here.
• Delivering the service you asked for — performance of a contract (art. 5/2-c). That service is: market data screens, news summaries written in our own words with a link to the source, the reading of KAP disclosures, AI-generated analyst commentary identities, the portfolio tracker you type your own records into, and the credit system.
• Operating your plan and your credit balance — performance of a contract (art. 5/2-c).
• Payment and invoicing — performance of a contract (art. 5/2-c). Not applicable today: there is no payment step on the site and no payment provider is connected. When payments open, this section will be updated with the real list of data collected.
• Securing the service, preventing abuse, rate limiting and keeping server access logs — the controller’s legitimate interest (art. 5/2-f).
• Meeting statutory retention and disclosure obligations and responding to the requests of competent authorities — legal obligation (art. 5/2-ç).
• Loading the TradingView chart in the VIX box — explicit consent (art. 5/1). The chart loads only when you press the box’s button yourself; once it loads, TradingView may set its own measurement cookies (Snowplow). There is no other third-party source of analytics on the site. How that consent is taken is described in section 5. The page-view counter on our own server sits outside this: it keeps one integer total per item, no identifier and no timestamp, and it sets no cookie — so it is not consent-based; its ground is legitimate interest (art. 5/2-f).
• Keeping the waiting list so that the launch announcement can be sent — explicit consent (art. 5/1). You leave your address yourself, by filling in the form, for that one announcement; if you do not, nothing changes, and joining the list does not require membership. The announcement has not been sent yet.
• Handling a Pro early-access request — at your request, as steps before entering into a contract (art. 5/2-c). A request is not a purchase and costs nothing; if you do not ask, nothing changes.
• Sending the newsletter and informational messages — explicit consent (art. 5/1). It is optional and unticked by default.

5. The two places explicit consent is genuinely taken — and withdrawing it

Explicit consent is the narrowest ground in the KVKK. We use it in the only two places where it is genuinely required. Both are separate acts; there is no single box that combines them.

(a) The TradingView chart in the VIX box. There is no cookie consent banner on the site; this is the one third-party component that depends on consent. The VIX box on the US equities page waits for our own data and offers to show TradingView’s chart beside it; right next to the button it says that pressing it connects your browser to TradingView and loads its code. Until you press it, your browser sends not a single request to TradingView and no third-party cookie is set. Once you do, the chart loads and TradingView may set its own measurement cookies. That click is the explicit consent within the meaning of art. 5/1 of the KVKK, and it holds for that one opening only.

Your choice is not stored: the chart is removed when you press “Close” or leave the page, and you are asked again on your next visit. Withdrawing consent is as easy as giving it — no email to write, no form to fill in, no reason to give. You can delete the cookies TradingView set on its own domain from your browser settings. Withdrawal takes effect going forward; processing carried out before withdrawal does not become unlawful, but it stops from that moment on.

(b) The newsletter. The newsletter box during sign-up is optional and unticked by default. If you leave it unticked nothing changes; your membership is unaffected. If you tick it, that preference is written to your record and the sending of commercial electronic messages rests on your explicit consent (art. 5/1). To change your mind, one line to info@mergen.finance is enough.

Beyond these, no processing rests on explicit consent. In particular: reading this notice, accepting the Terms of Membership, or creating an account is not explicit consent and is not presented as such. Creating an account is an act you take and it forms the contract; opening the VIX chart is a second, independent act. We do not condition processing that is necessary for the service to work on consent — because consent made a condition of the service is not freely given and would not be valid.

6. How personal data is collected

Your personal data is collected entirely by electronic means, through mergen.finance:

• during sign-up and sign-in, directly from you (the email link) or, if you choose it, from Google,
• from the records you type into the portfolio and preference screens,
• from the technical information your browser sends with every request,
• from cookies and browser storage.

We have no oral, written or physical collection channel. The legal grounds for collection are set out purpose by purpose in section 4.

7. Transfer abroad (KVKK art. 9)

All of our servers and infrastructure providers are outside Türkiye. We do not present this as “not a transfer”: hosting data in Germany or in the European Union is itself a transfer abroad within the meaning of art. 9 of the KVKK.

• Hetzner Online GmbH — Nuremberg, Germany. The servers the site and the API run on. Every request relating to your account passes through them. Legal basis: performance of a contract (art. 5/2-c); for the access logs, legitimate interest (art. 5/2-f).
• Supabase — on Amazon Web Services, inside the European Union; region: eu-central-1 (Frankfurt). Membership, authentication and database. Your account, portfolio and credit records live here. Legal basis: performance of a contract (art. 5/2-c).
• Cloudflare — global edge network. It sits in front of the Supabase API endpoint; your requests pass through it. Legal basis: performance of a contract and security (art. 5/2-c, art. 5/2-f).
• Resend, over Amazon SES — Ireland. Sends the sign-in link emails; your email address is passed to the provider in the process. Legal basis: performance of a contract (art. 5/2-c).
• Bugsink — Bugsink B.V., inside the European Union (per its data processing agreement; infrastructure: Hetzner, Nürnberg (DE)). Error reporting; errors on the site and in the API are reported here. A report carries: the type and message of the error, a stack trace, the lines of our own source code around the failure (sent for errors that happen on our servers; not for errors that happen in your browser), your browser information, the page you came from (the referer), and the address of the page the error happened on — including the query part after the question mark. Those last three apply only to errors that happen on the site’s own side; an error in the API carries the error alone, with no request information, no address and no browser information. In that address only the values of eight keys whose names denote a secret (code, token, key, secret, access_token, refresh_token, apikey, next) are removed; every other key, and its value, goes as it is. Never sent at all, structurally: your session cookies, the body of the request, the query-string field, the user record and the local variables of stack frames — these are dropped whole when the report is built. On top of that, anything in the outgoing text shaped like an email address, a JWT or a “Bearer” token is rewritten; because that is a shape match, an address carried in an unrecognisable form (percent-encoded, say) can get through, and we say so here. Errors that happen in your browser are sent to Bugsink directly from your browser, so whatever the report contains, your IP address reaches Bugsink. Retention is not defined in days: Bugsink keeps the number of most recent reports this installation is configured for and deletes the oldest once that number is reached. That is a setting in the provider’s own console; we cannot independently measure it. Legal basis: legitimate interest in keeping the service running and secure (art. 5/2-f).
• Google LLC — global, including the United States. Only if you choose “Continue with Google”. You can sign in with the email link without ever using this step; the choice is yours and it is plainly visible on the sign-in screen. Legal basis: operating the sign-in method you chose, that is, performance of a contract (art. 5/2-c).
• Binance — global. When a page shows live crypto prices (the crypto page, crypto symbol pages, the comparison desk and the watchlist in the side rail), your browser connects directly to Binance’s public price stream (stream.binance.com); your IP address and browser information reach Binance in the process. Your account, email address and portfolio are not sent. Legal basis: delivering the live prices you asked to see — performance of a contract and legitimate interest (art. 5/2-c, art. 5/2-f).
• TradingView — third-party chart. Only if you yourself press “Show on TradingView” in the VIX box on the US equities page. Once you do, your browser connects directly to TradingView; TradingView sees your IP address and your browser information, and its own privacy policy applies: https://www.tradingview.com/privacy-policy/. Legal basis: your explicit consent (art. 5/1 and art. 9). If you do not press it, that connection is never made.

The legal framework for the transfer. As of today the Personal Data Protection Board has issued no adequacy decision for these countries. The necessary infrastructure transfers above will therefore rest on the appropriate-safeguards route set out in art. 9; in our case that will take the form of a standard contract to be signed with the providers and notified to the Authority. Let us be plain: signing those instruments and notifying them is one of the steps to be completed before launch, and this text does not speak of it as done before it is done. When that step is complete, this paragraph will be updated to say which instrument was notified for which provider, and when.

To say it plainly: we do not claim to have taken your explicit consent for these transfers. Making a transfer that the service cannot run without depend on consent offers you no real choice, and such consent is not freely given. The only consent-based transfer is the TradingView chart in the VIX box; only you open it, and you are asked again each time.

8. Retention periods

• Account, profile, plan and credit records: for as long as your membership lasts. They are deleted from the live database when you ask for deletion or use the “Delete my account” button, and there is no backup or archive in which they are kept; records for which a statutory retention obligation has arisen are severed from your identity and kept for the period the legislation requires.
• Portfolio tracker records: until you delete them or your membership ends.
• Server access logs (IP address, browser information, requested address): 14–15 days. The nginx access log is rotated daily, 14 archived copies are kept and the oldest is deleted; so long as the log is written to every day, the window is between 14 full days and 15 days. This period is verified by the date of the oldest record that actually survives on the server, not read off a configuration file.
• Server error logs (the same IP addresses; requests that hit the rate limit or ended in an error): no fixed ceiling. The error log is rotated by the same rule, with 14 archived copies; but rotation is skipped on days when the file is empty. Those same 14 copies therefore cover a stretch appreciably longer than 15 days whenever errors are sparse — at the last measurement that meant a stretch of about nineteen days. Until the period is pinned to a number of days we do not describe this log as a 14–15 day one.
• Application logs (journald): bounded by size rather than by time — 1 GB at most. That bound is currently full, so the window is set by the volume of logging rather than by a period: more logging shortens it, less lengthens it. Today it reaches back about as far as the access logs, but that is a consequence of current volume, not an undertaking.
• Abuse and blocking records (fail2ban): 365 days, and indefinitely for permanently blocked sources. These are kept for sources that try to log in to the server; an ordinary site visit’s IP address does not enter them — the rules enabled today watch SSH login attempts and repeat offenders, nothing else. What is kept is not only the address: beside nearly every record we also store the raw log lines that show the attempt, including the username that was tried. A source blocked five times in quick succession is blocked permanently, and its record is exempt from the 365-day purge and kept indefinitely. The 365 days is read from the setting rather than measured; the store is not yet that old.
• Cookies and browser storage: the duration of every item is written out one by one in the Cookie Policy. The one that matters most legally is the session cookie: 30 days, but that period runs from your last visit — it is renewed every time you use the site, and it expires if you stay away for 30 days.
• Launch-notification list: the email address you left in order to be told about the launch, the language you were reading the page in, and — if there was one — the invite code that brought you. This record is not attached to an account; you do not need an account to be on the list. It stays until someone asks for it to be deleted: there is no mechanism that deletes it because a period has expired. If you delete your account, this record is deleted with it only when it sits under the same address as the account; under a different address it is not found and is not deleted. The launch announcement has not been sent yet; when it is, the link in that email will delete the row rather than merely unsubscribe it. The route that works today is this: write to info@mergen.finance and we will delete that row.
• Pro early-access request: until it is settled, one year at most. It is deleted within 30 days of Pro sales opening; a request a year old is deleted by the nightly job. To have it deleted sooner, write to info@mergen.finance.
• Access request (“Request access”): until it is settled, then 12 months; deleted by the nightly job.
• Plan box measurement (no identity): single records 90 days, then daily totals only.
• Payment and invoice records: once payments open, they will be kept for 10 years (the period tax and commercial legislation requires); if your account is deleted the record stays, severed from you. No such record is created today.

The principle is this: data is deleted when the purpose of processing has fallen away and any statutory retention obligation has ended. When your account is deleted, the records attached to it (portfolio, credit ledger, preferences, your address on the launch-notification list) are deleted with it, out of the live system; there is no backup they could be brought back from. That the launch-notification row is looked for under the address on your account only, and is not deleted when it sits under a different address, is written in the list above.

A nightly job deletes records whose period has expired; how long each record is kept and the mechanism that deletes it are set out record by record in the Retention and Destruction Policy. Account deletion is self-service: the “Delete my account” button on the Profile page deletes the account and the personal records attached to it from the live database while you wait — you do not queue behind an application. That is not the same as saying every trace disappears at once. There is no backup or archive holding the deleted records, so they cannot be brought back; but records for which a statutory retention obligation has arisen are not deleted by that operation either — they are severed from your identity and kept for the period the legislation requires — and the server logs go on keeping your connection details on the terms written in the list above. The record of your deletion request stays as well: the account identifier and the dates, as the proof you exercised the right; the same nightly job deletes it after three years. The Privacy Policy says the same thing; the two texts must not diverge on this.

9. Your rights as a data subject (KVKK art. 11) and how to apply

Under Article 11 of the KVKK, by applying to the data controller you have the right to:

• a) learn whether your personal data is being processed;
• b) request information about it if it has been processed;
• c) learn the purpose of processing and whether the data is used in accordance with that purpose;
• ç) know the third parties, in Türkiye or abroad, to whom your data is transferred;
• d) request correction where the data has been processed incompletely or incorrectly;
• e) request erasure or destruction within the conditions of art. 7 of the KVKK;
• f) request that operations carried out under (d) and (e) be notified to the third parties to whom the data was transferred;
• g) object to a result adverse to you arising from analysis of the processed data exclusively by automated systems;
• ğ) claim compensation for damage suffered because your personal data was processed unlawfully.

How to apply. You may send your requests by email to info@mergen.finance. Making the application from the email address registered to your account helps us verify your identity and speeds things up. Your application will be concluded as soon as possible and within thirty days at the latest (art. 13/2). This is free of charge; where the operation entails a separate cost, the fee in the tariff set by the Board may be charged. For account deletion you need not wait for an application to be processed: the “Delete my account” button on your Profile page deletes the account and the personal records attached to it while you wait. What that operation covers, and what it does not reach, is set out in section 8.

For consent-based processing, withdrawing consent requires no application: for the VIX chart, pressing “Close” or leaving the page is enough; for the newsletter, one line to info@mergen.finance (section 5).

If your application is refused, if you find our answer insufficient, or if you receive no answer in time, you may lodge a complaint with the Personal Data Protection Board within thirty days of learning our answer and in any event within sixty days of the date of application (art. 14).

10. Changes

This notice is updated when the data processed, the purposes, the legal grounds or the recipients change, and the current version is always published on this page. The cookie list is kept in the Cookie Policy rather than here, and is updated there. Should a cookie that needs consent or a new third-party component ever be added, you will be asked before it is.

11. Governing text

The Turkish version of this document governs. This English translation is provided for convenience only; in a dispute the Turkish text prevails.

12. Contact and data controller

Data controller: Mergen Finance — Ediz Emre Yıldırım.

Address for applications and contact: info@mergen.finance. How to apply, and the time limit for an answer, are set out in section 9.