Privacy Policy

1. Who we are (data controller)

Osii (business registration 247-70-00655), represented by 이재원 (Lee Jae-won), is the controller of the personal data described here.

Registered address: S189, Bldg 603, 26-21, Dongtanjungsimsangga 2-gil, Dongtan-gu, Hwaseong-si, Gyeonggi-do, 18453, Rep. of KOREA. Contact: support@scorvo.io. For data-protection requests specifically, write to privacy@scorvo.io.

2. Whose data, and what we collect

Operators. When you create an operator account you sign in through our authentication provider. We process your email address and display name to identify your account and secure it. We do not see or store your password. When you accept an invitation into someone else's club, the address you accepted with is written into that club's invitation record, so its owner can see who joined.

Players on a roster. Operators enter the people in their club — names, and the results and statistics of matches. Where an operator has turned it on, we also hold whether each of those people is coming to a session, as the operator or anyone holding that session's link has recorded it (section 4). An operator can also attach a photo of a player and write a private note about them; neither of those two ever appears on a page shared outside the club. Most players never hold an account with us; they are records an operator keeps. We do not ask for dates of birth, or for anything else whose purpose is to record how old a person is. That limit is not a complete one: the note is free text and the photo is a face, so those two hold whatever the operator puts there.

Uploads. When an operator imports results, the uploaded photo, PDF, or spreadsheet is stored so it can be read and so each figure can point back to its source. Extraction reads the file to draft rows; nothing is published until the operator confirms.

The in-app assistant. When an operator uses the assistant, what they typed, what it answered, and which actions it proposed are kept on the account, so that a conversation carries on from one turn to the next. Separately, every change made in the product — by hand or through the assistant — is written to a change record and an activity feed, which hold the values that were entered and the name of the operator who entered them.

Assistants an operator connects. An operator can also connect an outside AI client to their club — one that speaks the same protocol we publish. That client reads the club through us — the roster, the schedule, the standings, a player's statistics, whichever the operator's request needs — and, where the request calls for it, changes the club the same way the operator could; those changes are written to the change record and activity feed described above. It is the operator's tool rather than ours, so what it does with what it reads is governed by whoever provides it; on our side we record which clients are connected and when each was last used.

Payments. Subscriptions and credit top-ups are handled by our payment provider as merchant of record. Card details go to that provider, not to us. The rest of the transaction does reach us: the provider's customer and subscription identifiers, the plan and its billing cycle, whether the subscription is active, past due, or cancelled, when the paid period ends, and the amount of an order together with any refund against it. The provider also passes us the email address you gave it — that is the address your billing email goes to, and we keep it on the delivery record of each message we send. In the other direction, when you open a checkout we pass the provider your IP address, which is how it settles the currency to charge you in.

Why you left. If you cancel a subscription that was charged at least once, we ask you once, after the cancellation is already final, why you are going: a reason from a short list and, if you want to add one, a sentence in your own words. Both are optional; both are kept with the workspace whose subscription you cancelled. The reason you pick is also passed to our payment provider. The sentence you write is not — it stays with us. A subscription whose first payment never completed is not a departure and we do not ask.

Waitlist visitors. If you leave an email address for a launch notice, Clerk, our authentication provider, holds it rather than our database. Joining the waitlist means Clerk sends you a confirmation email, and at the launch we send the launch notice, which goes out as a Clerk invitation from the waitlist. The address is used for those two emails and for nothing else, and we send no marketing email. Section 6 says when we delete an entry whose invitation you did not accept and an entry we never sent a notice to, and how to have yours deleted sooner.

Visits. Every page reports a page view to our analytics provider so we can see which parts of the product are used. We set no cookie for it, and that provider states the measurement is not tied to an individual. Page addresses that are themselves credentials — a share link, a club invitation, the link that stops a pending account deletion, the link that opens a receipt for a payment we returned — are rewritten to a placeholder in your browser before that page view leaves it.

3. Why we process it (legal bases)

To provide the service you asked for — running your club's competitions — which is the performance of our contract with you (GDPR Art. 6(1)(b)).

To send you the confirmation email for joining the waitlist and the launch notice you asked for by leaving an address there — the steps taken at your own request before entering into a contract (GDPR Art. 6(1)(b)); that address is used for those two emails and for nothing else, and we send no marketing email.

To keep the service secure, working, and improving, which is our legitimate interest (Art. 6(1)(f)), balanced against your rights.

To defend ourselves if we are told we did not erase something we were asked to erase — a complaint, a supervisory authority's enquiry, or a claim — which is our legitimate interest (Art. 6(1)(f)) and, for records kept from the moment an erasure begins and after it has been carried out, the ground Art. 17(3)(e) leaves open. The records concerned are the lines described in section 6 that say a deletion happened and on what day, which carry no name, address or account, and which no law obliges us to keep. You can object to that processing at any time (Art. 21), and section 7 says how.

To meet legal obligations such as tax and accounting records tied to payments (Art. 6(1)(c)).

4. Players' names on shared pages

A club's standings can be shared as a link, and two settings on that link decide what a visitor meets. The first is who may open it. A private link opens for nobody. An unlisted link and a public link behave identically — each opens for anyone holding the address — and what separates them is the operator's intention to circulate it, not anything we enforce differently. The second is how players are named; by default the page prints the given name alone. An operator who wants family names on that page turns that setting on, and the page then prints the full name the operator entered. The two settings are independent: making a link unlisted does not change how players are named, and neither does making it public.

That setting has a limit. When family names are off and there is no separate given name on file — typically because a roster was pasted with one name per line — what appears is the first word of the full name, the initial of the second word, and a period, such as Maria L. for Maria Lopez Garcia. A full name of one word, typical of Chinese, Japanese, or Korean names written without spaces, is shown whole. If a full name is written family name first, the kept first word is the family name. The setting reduces the name shown; it does not guarantee a family name never appears. The same shortened form names players in the match titles on the club's own inbox and activity screens, and in the schedules, standings, and match results the assistant looks up. The assistant is also given the roster with the names as the operator entered them (section 5), so an answer it writes can still use a full name.

A shared page shows either one tournament, with its results and standings, or a single day of a weekly session: the games still to play, each with its court where one is set, the results, and the standings. Once that day is over, its page can also show a short line about how the day went. An AI model writes it from the day's results and standings, and sometimes from how the standings moved since the session's previous day of play (section 5 names its provider). No player's name is sent to that model; we put the names in afterwards, in the form this section describes. A visitor who picks their name on a session's page sees their own games first; which name a visitor picked is kept on that visitor's device only, and we do not store it. Where the operator has turned on answers for a session, the shared page for that session's current day also lists the people on the club's roster — archived people are left out, each is named the way this section describes, and no more than two hundred names are listed — and shows beside each the answer recorded for them: coming, on the waiting list, or not coming. Until that day starts, anyone who holds the link can leave an answer for any person on that list, and a first tap on a name that has no answer yet both picks that name and answers that the person is coming; we store the answer, the time it was given, and whether it came through the link or from the operator, and we do not check or record who tapped. The operator can change any answer, and can turn this off, which takes the list off the page and leaves the answers already given in the club's records; once the day has started the list keeps only the people an answer was recorded for. There is no public page of an individual player's statistics — no such page exists outside the club's own screens. Team lineups are the one further section an operator can open, and a link is created with them closed. Player photos and operators' notes are never on that page at all.

A player who has results is not deleted when an operator removes them from the roster; they are archived, which takes them off the club's roster screen and leaves them named where those results are already published. A player who is referred to nowhere else — no result, no team, no tournament entry — is deleted when removed.

5. Who else receives it, and where

We use these companies, each for a stated purpose: Clerk (account authentication, and the launch waitlist — holding the email address you leave there so that Clerk sends you the confirmation email when you join and we send the launch notice when sign-up opens), Convex (application database), Vercel (application hosting), Vercel Web Analytics (cookieless visit measurement), Cloudflare R2 (file storage — uploaded import files, player photos, and the daily database backup), OpenAI (reading uploaded files to draft import rows, running the in-app assistant, and writing the line about a finished session day from its results and standings, for which no player's name is sent), Polar (payment processing, as merchant of record), Resend (sending the service email we send you), Sentry (error and performance diagnostics — set not to attach IP addresses or request bodies, while request headers and cookies are attached with sensitive-looking names filtered out), Google (Maps Platform for venue address search, and Workspace for the mailboxes that receive what you write to us), and GitHub (source hosting, and the scheduled job that takes the daily database backup).

A turn with the assistant carries the context it needs in order to act on your club — the club's name and time zone, the language you use Scorvo in, its venues, its teams, and its roster, which is to say the players' names as you entered them. And the address search reaches Google from the operator's browser rather than from our servers, so Google sees that request the way it sees any website's map search.

We are based in the Republic of Korea, and each company below processes your data where its block says, as far as that company's own pages we could read state it, or, where a block says so, what our own requests show. Where a block names a legal ground under Korean law, it is the ground for the people that block names. For readers in the EU or EEA, where a company's terms that bind us include safeguards for these transfers — such as standard contractual clauses or the EU-U.S. Data Privacy Framework — those safeguards are what the transfers rely on.

Your data reaches Clerk, Inc., in the United States.

• Legal ground: for operators, anyone who pays, and anyone who left an address for the launch notice, signing in and sending the waitlist's confirmation email and launch notice are processing we entrust to Clerk because our contract with you needs it — for the address, the step you took at your own request before entering into a contract — and Korea's Personal Information Protection Act allows it to go abroad when this policy discloses it (Article 28-8, paragraph 1, item 3(a)).

• What goes there: the email address and name on your account, the sign-in sessions of the devices you use with the network address and browser each request comes from, and, for the launch waitlist, the email address you leave there, the confirmation email Clerk sends when you join, and the invitation Clerk sends at the launch.

• Where, when and how: each time you sign up, sign in or stay signed in, from your browser and from our servers over an encrypted connection, to Clerk's servers in the United States; when you leave an address for the launch notice, from your browser to Clerk, which keeps it in the waitlist for our instance and sends the confirmation email when you join; at the launch the notice goes out from that waitlist as an invitation Clerk sends, and we delete the invitation there; Clerk's sign-up form can also run a Cloudflare Turnstile check in your browser, which Clerk names as its protection against bots.

• Who receives it: Clerk, Inc., whose published privacy contact is privacy@clerk.dev.

• Why, and for how long: to let you sign in and keep your account secure, and to hold a launch waitlist address so that Clerk can send the confirmation email when you join and we can send the launch notice, and for nothing else — we send no marketing email; a launch waitlist entry whose invitation is not accepted is deleted with its invitation as section 6 describes, and an entry we never sent a notice to is deleted as section 6 describes; your sign-in is removed from Clerk when your account is erased, as section 6 describes, and by its terms Clerk deletes what it holds for us within 90 days after our agreement with it ends.

• If you refuse: signing in cannot work without Clerk, so refusing means not creating an account, or deleting the one you have as section 6 describes; the waitlist's confirmation email and launch notice reach you only through Clerk's waitlist, so refusing them means not leaving an address there.

Your data reaches Vercel Inc., for hosting, in the United States.

• Legal ground: for operators and anyone who pays, hosting what our application handles is processing we entrust to Vercel because our contract with you needs it, and Korea's Personal Information Protection Act allows it to go abroad when this policy discloses it (Article 28-8, paragraph 1, item 3(a)).

• What goes there: every request you make to Scorvo and what it carries; the usage data and logs Vercel creates about its own service fall under Vercel's own privacy notice, not the ground above.

• Where, when and how: continuously while you use Scorvo, over an encrypted connection: our application runs in Washington, D.C., in the United States, Vercel's default region, and our own requests from Korea on 2026-10-07 entered Vercel's network in Seoul.

• Who receives it: Vercel Inc., whose published privacy contact is privacy@vercel.com.

• Why, and for how long: to run Scorvo; Vercel keeps our application's logs for 1 day on our plan and, by its terms, deletes our content within a commercially reasonable time after our agreement with it ends.

• If you refuse: Scorvo cannot run without its host, so refusing means not using Scorvo, or deleting your account as section 6 describes; a player on a roster asks the operator who keeps it, as section 7 describes.

Your data reaches Convex, Inc., in the region set on our database — one of the four Convex offers: the United States, Ireland, Australia or Canada.

• Legal ground: for operators and anyone who pays, keeping the service's records is processing we entrust to Convex because our contract with you needs it, and Korea's Personal Information Protection Act allows it to go abroad when this policy discloses it (Article 28-8, paragraph 1, item 3(a)).

• What goes there: everything Scorvo keeps — accounts, clubs, rosters, results, answers, notes, photo references, conversations with the assistant, and the records section 6 describes.

• Where, when and how: continuously while the service runs, from our servers and from your browser over an encrypted connection, to the region set on our database, where Convex says all of it is hosted.

• Who receives it: Convex, Inc., whose published privacy contact is privacy@convex.dev.

• Why, and for how long: to hold the service's data for as long as section 6 says we keep it; by its terms Convex deletes our data when our agreement with it ends, apart from backup copies it deletes on its own schedule.

• If you refuse: the service cannot run without its database, so refusing means not using Scorvo, or deleting your account as section 6 describes; a player on a roster asks the operator who keeps it, as section 7 describes.

Your data reaches Cloudflare R2 (Cloudflare, Inc.), in the location Cloudflare gave our storage when it was set up — by default the region nearest to where it was set up from.

• Legal ground: for operators and anyone who pays, keeping the files you upload and the photos you add is processing we entrust to Cloudflare because our contract with you needs it, and Korea's Personal Information Protection Act allows it to go abroad when this policy discloses it (Article 28-8, paragraph 1, item 3(a)).

• What goes there: the files you upload for import, the photos of players you add, and once a day a snapshot of our whole database, which falls outside the ground above.

• Where, when and how: files and photos go from your browser over an encrypted connection when you add them, and the snapshot goes from our scheduled job every day at 03:00 Korean time, also encrypted; Cloudflare says staff of its companies in other countries may need to reach them to give support.

• Who receives it: Cloudflare, Inc., whose published privacy contact is dpo@cloudflare.com.

• Why, and for how long: to keep files and photos for as long as section 6 says we keep them, and each snapshot for 30 days, which our backup job sets; by its terms Cloudflare deletes or returns what it holds, as we choose, when our agreement with it ends.

• If you refuse: files and photos cannot be kept without this storage, so refusing them means not uploading files or adding photos and the rest of Scorvo keeps working, while the snapshot cannot be refused apart from the service, so refusing it means deleting your account as section 6 describes; a player asks the operator who keeps the roster, as section 7 describes.

Your data reaches OpenAI, in the locations its subprocessor list names, which we could not open — the pages we could read do not give the company's legal name.

• What goes there: the files you upload for import; in a turn with the assistant, what you and it say, the club's context and roster, the language you use Scorvo in, and what it looks up to answer you; and a finished session day's results and standings without any player's name.

• Where, when and how: from our servers over an encrypted connection, each time you import a file or use the assistant, and when a session day is over.

• Who receives it: OpenAI, whose published privacy contact is privacy@openai.com.

• Why, and for how long: to read your files, answer you and write the line about a finished day; OpenAI says it does not train its models on this data, keeps logs that can hold it for up to 30 days to watch for abuse unless a law or the need to prevent harm calls for longer, and, because our requests leave its storage setting at the default, keeps each response for at least 30 days.

• If you refuse: the assistant and file import reach OpenAI only when you use them, so refusing means not using them and the rest of Scorvo keeps working, while the line about a finished day goes without any player's name; a player on a roster asks the operator who keeps it, as section 7 describes.

Your data reaches Resend (Plus Five Five, Inc.), in the United States.

• Legal ground: for operators and anyone who pays, sending the service email we owe you is processing we entrust to Resend because our contract with you needs it, and Korea's Personal Information Protection Act allows it to go abroad when this policy discloses it (Article 28-8, paragraph 1, item 3(a)).

• What goes there: your email address and the subject and text of each service email we send you; the details of our own account and the usage data Resend records about its own service fall under Resend's own privacy policy, not the ground above.

• Where, when and how: from our servers over an encrypted connection each time we send you a message, and stored in the United States whichever route the mail takes.

• Who receives it: Plus Five Five, Inc., whose published privacy contact is privacy@resend.com.

• Why, and for how long: to deliver the messages this policy mentions; Resend says it keeps email and log data for 30 days on its standard plans and deletes the rest of what it holds for us within 90 days after our account with it ends.

• If you refuse: most service email comes with an account, so refusing it means not creating one, or deleting yours as section 6 describes; an invitation reaches you only because an operator invited your address, and a confirmation only because you used our public cancellation or withdrawal form.

Your data reaches Polar Software, Inc., in the United States, Canada or other countries, by Polar's own statement.

• What goes there: your network address when you open a checkout, the reason you pick when you cancel, and our requests to cancel or refund a subscription, together with what you type into Polar's own checkout, such as your card details and email address.

• Where, when and how: from our servers over an encrypted connection when you open a checkout, cancel, or delete your account, and from your browser when you pay in Polar's checkout.

• Who receives it: Polar Software, Inc., whose published privacy contact is privacy@polar.sh.

• Why, and for how long: to sell you the subscription or credits as merchant of record, under Polar's own privacy policy; Polar says it keeps your data while you hold an account with it or as its services need, and longer to meet a legal obligation, settle a dispute or collect fees owed, or where a law permits or requires it.

• If you refuse: only paying needs Polar, so refusing means not buying a subscription or credits and the free plan keeps working, and what Polar already holds stays in Polar's own records, as section 6 says.

Your data reaches Google LLC and its affiliates, for Maps Platform, in countries Google's Maps terms do not name.

• What goes there: what you type into a venue's address field and the position of a venue whose place is set when its map is drawn, with your browser's network address on each request, which Google receives as its own under its privacy policy.

• Where, when and how: from your browser, over an encrypted connection, when a venue's address field opens and as you type in it, and when a venue's map is shown — not through our servers.

• Who receives it: Google LLC and its affiliates, whose published privacy contact is https://support.google.com/policies?p=privpol_privts&hl=en.

• Why, and for how long: to suggest the place you are looking for; Google's Maps terms let Google use and keep this data to provide and improve its products, under its own privacy policy, and name no period.

• If you refuse: only the venues screen and a venue's address field use Google — the screen draws a map of each venue whose place is set — so refusing means not opening that screen or adding a venue's address, and the rest of Scorvo keeps working.

Your data reaches Google Asia Pacific Pte Ltd, for Workspace, in any country where Google or its subprocessors keep facilities, by Google's terms.

• What goes there: the messages you send to our addresses — what they say, who sent them, and any attachments — and our replies.

• Where, when and how: when you write to us, your mail provider delivers the message straight to Google, where it stays in our mailboxes; Google's terms name this company for a Workspace customer billed in Asia-Pacific outside Australia, India and New Zealand.

• Who receives it: Google Asia Pacific Pte Ltd, whose published privacy contact is https://support.google.com/policies?p=privpol_privts&hl=en.

• Why, and for how long: to read and answer what you write; a message to us is not part of what an account holds, so erasing an account does not remove it; we keep it, and our replies to it, in our mailboxes for 3 years after the last message in its thread, and keep longer any one of them that section 6 says a law obliges us to keep.

• If you refuse: you can choose not to write to us by email and the rest of Scorvo keeps working, but every contact this policy gives for a question or a request under section 7 is an address in these mailboxes, so writing to it means passing through Google.

Your data reaches Sentry (Functional Software, Inc.), in the United States.

• What goes there: reports of errors and slow pages from our servers and your browser — the page's address, the request's headers and cookies with sensitive-looking names filtered out, and the details of what failed — set not to attach your network address or the body of a request.

• Where, when and how: from our servers and your browser over an encrypted connection, when something fails or a page's speed is measured, to the data region Sentry keeps in the United States.

• Who receives it: Functional Software, Inc., whose published privacy contact is compliance@sentry.io.

• Why, and for how long: to find and fix faults; by Sentry's published defaults it keeps error reports for 30 or 90 days and performance data for 30 days, depending on the plan.

• If you refuse: error reports are part of keeping the service working, so refusing means not using Scorvo, or deleting your account as section 6 describes; you can also object to this processing as section 7 describes.

Your data reaches Vercel Inc., for Web Analytics, in the United States, where Vercel's terms place its primary processing.

• What goes there: a page view from every page — its address with secret links replaced, the page you came from, your rough location, and your device type, operating system and browser — which Vercel says is not tied to you, your account or your network address.

• Where, when and how: from your browser over an encrypted connection each time a page opens; Vercel tells visits apart by a hash of the request rather than a cookie, and says that hash cannot follow you across days or across sites.

• Who receives it: Vercel Inc., whose published privacy contact is privacy@vercel.com.

• Why, and for how long: to see which parts of Scorvo are used; Vercel discards each visit's session after 24 hours, keeps the page views to report on for 12 months on our plan, and says it may keep them longer.

• If you refuse: Scorvo has no setting that turns this off, so refusing means not opening its pages; you can also object to this processing as section 7 describes.

Your data reaches GitHub, Inc., in the United States and other countries where GitHub operates, by its own statement.

• What goes there: once a day, a snapshot of everything our database holds, while our scheduled job passes it on to our storage at Cloudflare.

• Where, when and how: every day at 03:00 Korean time our scheduled job runs on a GitHub machine, fetches the snapshot and uploads it to our storage at Cloudflare, each over an encrypted connection.

• Who receives it: GitHub, Inc., whose published privacy contact is dpo@github.com.

• Why, and for how long: to take the daily backup section 6 describes; the job uploads no copy of the snapshot to GitHub, and GitHub keeps the job's own logs for 90 days by default.

• If you refuse: the backup protects everything our database holds and cannot be refused apart from the service, so refusing means not using Scorvo, or deleting your account as section 6 describes; you can also object to it as section 7 describes, and a player on a roster asks the operator who keeps it.

We list the companies Scorvo uses to handle your data, and the mail service that receives what you write to us, as they stand on the date at the top; each passes data on to its own subprocessors under its own terms, and if our list changes, this policy changes with it.

6. How long we keep it

We keep account and club data while the account is open; a club you delete yourself can be restored for twenty-four hours and is erased after them. Asking us to delete your account ends your access to Scorvo and starts a twenty-eight-day grace period, and we ask our payment provider to cancel a subscription that is still billing on a workspace that has no other administrator. Those twenty-eight days exist to protect what the account holds, so an account that holds nothing does not get them: if you have never created or joined a club, there is nothing of yours here to erase later and nothing being billed, and asking us to delete such an account removes your sign-in there and then. That deletion is immediate, there is no grace period to stop it in, and nothing brings it back. Which of the two is about to happen is stated on the screen you confirm on. If we cannot reach our own records at that moment that screen describes the twenty-eight-day case, and we will not then carry out the immediate kind against it: an account that turns out to hold nothing is not deleted on the spot from a screen that promised a wait — nothing changes and the screen is brought up to date so you can read it again. An account that does hold something is accepted as the screen described, because that is what the screen said would happen. The rest of this section describes the twenty-eight-day case. The way you sign in is not removed at that moment — it is removed at the end of those twenty-eight days, together with everything else, so that the account can be reached and the deletion stopped while they run. Twenty-eight days is the wait, and every deletion that gets one gets those twenty-eight days. Where we sent a message when the request reached us, that message names the day the wait runs out, and the erasure begins on the first night after that — the night of the day the message names, or the night after it. The erasure runs in stages, can take more than one night, and is held in the two cases described below. The pages you shared out of the clubs that go with that account stop opening at the moment we receive the request, rather than at the end of those twenty-eight days — nothing about them is erased yet, but nobody can read them while the grace period runs. When those twenty-eight days are up, the erasure begins by itself and without you having to ask, on the first night after the wait runs out — whether or not we were able to write to you. What it takes is the rest: the clubs of the workspaces you alone administered and everything in them — the roster, the results and statistics, the shared links, the files uploaded into them, the record of what those workspaces' credits were spent on — and, wherever they were held, the conversations you had with the assistant. Money records of a workspace that outlives you keep their reference to the account, stripped of what identifies you. When that erasure has run we write to the address the account signed up with to tell you it is done, what it covered, and what is left after it — after the erasure rather than before it, because until then it has not happened. If we hold no address for that account, or the erasure runs across more than one night, there is nothing for us to write to and no message goes. And if the message could be written but our own mail is not going out — a fault on our side rather than a fact about your account — it does not go either; that is a failure to tell you something we owe you rather than a case we are excused from, the record described below says so by saying nothing, and writing to privacy@scorvo.io still reaches a person who will answer.

A club that belongs to someone else, one you were invited into, is not yours to erase and stays. Your membership of it goes, and so does anything the club holds that is about you rather than about the club — but two things remain, because they are that club's own record rather than yours: the invitation you accepted, which is how its owner can see who joined and with what address, and any file you uploaded into it, which is the provenance of results that club has published.

Erasure is the default. What survives it is what a law obliges us to keep — two things, described here — and the three records this section names further down, each with its reason and its period. The first is the record of money: the subscription itself, the orders, the credits an order granted, any refund against it, and the delivery record of the messages we sent you about them. The second is any formal cancellation or withdrawal you sent us — the statutory notice itself, which by its nature records who declared what, and which we therefore keep as you wrote it.

The periods are set by law rather than by us. Korean e-commerce law sets five years for records of a contract, a withdrawal, a payment, and what a payment supplied; Korean tax law sets five years from the filing deadline for the books behind them; German commercial and tax law set eight years for accounting vouchers and six for business correspondence, and ten for the accounting records those vouchers support. We keep the whole set for ten years from the erasure, because it hangs together on one record and taking part of it away early would leave the rest unfindable; ten is the longest period any of those laws puts on any part of it, and we do not hold it longer. A cancellation or withdrawal sent through the public form is not always tied to an account — a withdrawal never is, and a cancellation only when the address you give us matches one. Neither those declarations nor the confirmations we send for them have an account to hang from, so they run on their own clock instead: six years from the end of the calendar year in which they reached us, which is what German commercial law puts on a business letter we received.

From the moment we erase the rest, we take out of that record everything that identifies you and is not the record itself: your sign-in is deleted at the authentication provider, the link to it becomes an internal reference, and the address and the wording on a delivery record are replaced. If the authentication provider will not accept that deletion we hold the whole erasure rather than perform half of it, and we check for that state every day. Two things stay as they are. A cancellation notice keeps its declarant, because who declared what is the whole point of that document. And the payment record keeps our payment provider's own identifiers — for you, for the subscription, and for any payment we returned to you — because that is what makes it the record of a real transaction, and it means the provider, who is the merchant of record, can still connect it to you in its own books. Deleting your account here does not delete their customer record, and how long they keep it is theirs rather than ours. When those ten years are up, the payment record and the internal reference that replaced your sign-in are erased too.

Two things hold for those twenty-eight days. The first is that nothing is erased while they run, so a deletion made by mistake can still be stopped, and the shared pages we closed open again if it is. The second is that if our payment provider has still not accepted the cancellation when the twenty-eight days end, we hold the erasure until it does, so that a charge is never left standing with no record of whose it was; we check for that state every day.

Three routes reach that stop: opening Scorvo, where the control on the account screen stops it in one step; the link in the message we send when a deletion request reaches us, which opens without any sign-in; and a message to privacy@scorvo.io, which we act on by hand and which has to reach a person before the erasure begins — so a message sent on the last day may arrive after the night that starts it.

Not every account has all three. Which of them stay open to you depends on your sign-in and on the message we send when a deletion request reaches us — whether it reached you, and whether it carried a link.

• If your sign-in was removed at the authentication provider rather than here — you removed it there, or we did on request — the first route is closed to you, and where the message we sent carried a link that link and a message to us are the two that remain, though finishing the stop through the link then means signing up again on the address that message went to.

• Not every one of those messages carries such a link, and where yours carries none and you can still sign in here, the control on the account screen and a message to us are the two that remain.

• Where yours carries none and your sign-in was removed at the authentication provider, a single one remains: a message to us before the erasure begins.

• And if that message never reached you — we hold no address for the account, the address we hold turned it away, we could not put the message together, or our own mail was not going out at the time — the second route is not there either, and where you can still sign in here, the control on the account screen and a message to us are the two that remain.

• A message can also be on its way rather than gone for good, and where it carries a link that link is not yours to open until it arrives: where you can still sign in here, the control on the account screen and a message to us are the two that remain in the meantime.

• Where your sign-in was removed at the authentication provider and that message has not arrived yet, a single one remains until it does: a message to us before the erasure begins.

• If your sign-in was removed at the authentication provider and that message never reached you either, both of those routes are closed and a single one remains: a message to us before the erasure begins.

The account comes back attached to the same records either way. Two things do not come back with it. A subscription set to end when the deletion was accepted is still set to end, and resuming it is a separate act on the billing screen. And a club in a workspace someone else administers can remove you from its members while the twenty-eight days run; stopping the deletion opens the workspaces you alone administered again, but it does not put you back into someone else's.

Uploaded import files are kept as the provenance of the figures read from them, for as long as the club that holds them is kept — which is why an upload into someone else's club outlives your account. A cancellation reason is kept with the workspace it was written for and outlives the subscription it describes — it can only be written after that subscription has been cancelled, only while nothing else on the account is being charged, and only for a subscription that was charged at least once — and it is erased with the account, because it is a survey we asked rather than a record we must keep.

One record is neither yours nor kept by law, and it survives the erasure. Each message our payment provider sends us leaves a line in our systems — which message, of what kind, when it arrived, and what we did with it — so that the same message arriving twice cannot charge you twice. A line about a payment — an order or a refund — is part of the payment record above and keeps that record's ten years, whether or not it names one of your subscriptions, because for a payment we could not match to an account it is the only trace we hold of it. The rest hold no name, address or account of yours, and we delete those messages ninety days after they reach us.

A second record is neither yours nor kept by law, and it is here because of an erasure rather than in spite of one. Our basis for it is the legitimate interest stated in section 3. When a deletion is requested, when one is stopped, when the erasure begins destroying what the account holds, when it is finished, when we ask our authentication provider to delete the sign-in of an account that held nothing, when that provider tells us somebody removed a sign-in there without ever having had anything of theirs here, and when a fresh sign-in is attached to an account whose previous sign-in had gone, we keep one line saying that it happened and on what day. The third and the fourth are two lines about one erasure, and they are separate because an erasure can begin and not finish: it runs in stages, night by night, and if it stops part way — because our payment provider has not accepted a cancellation, or because the work outruns what one night can do — the line saying it began is the only record that anything was destroyed. The fifth is written at the moment we ask rather than after the provider answers, so it records a deletion we set in motion; if the provider refuses, the line stands and nothing was deleted. Both lines about an erasure also record the day it was asked for, because how long we took is the thing a complaint asks about; and the line saying it is finished records whether we sent the message telling you it had happened — the fact on its own, not the address it went to, and only once that message was actually on its way. That fact is kept here, on a line that lasts ninety days, rather than on the message's own delivery record, which is erased after thirty days. Each line carries a day rather than a time of day, and no name, no address, and no account: in place of the sign-in it refers to, it holds a one-way fingerprint of it, so the line names nobody and cannot be read back to a person from the line itself. While an account is still open we hold the sign-in it was made from, so we could still match the two; once the account is erased, what the fingerprint was made from is gone from our systems, and matching it would need an identifier somebody already had. We keep each record of the deletion for ninety days from the day its line is written, and then erase it too — so the line saying an erasure was carried out runs its ninety days from the erasure itself, and the line saying one began runs them from the day it began. It is there so that we can show what we erased and when, after the accounts themselves are gone — which is what a complaint or a supervisory authority's enquiry asks us for, and what a record the erasure erased could not answer.

One more record has your address on it rather than a pseudonym, and it is the message itself. Whenever we delete an account we write to the address it signed up with to say so — at once for an account that held nothing, and on the day the erasure runs for every other one — and each of those messages leaves a delivery record: the address, the subject, and whether it was sent. Neither of them can hang from an account, because the first never had one and the second is written in the same moment the account is destroyed, so each delivery record runs on its own clock: we delete it thirty days after it is written. What survives that is only the line described above, which names nobody. Not every deletion can be written to; these are the cases. If a sign-in is removed at our authentication provider by somebody who never created or joined a club here, all we are told is that it happened and we hold no address of theirs to answer to. If an account never received a message from us at all, that is usually because we have no address on file for it, and sometimes because the address we hold would not take the message, because we could not put it together, or because our own mail was not going out at the time — and that last one is a fault on our side, so it holds for every account we delete while it lasts rather than for some of them. And if an erasure has to run across more than one night, the address is taken out of our records before the erasure finishes, so the message cannot be sent afterwards. In each of those cases the pseudonymous line described above is the whole of what we can do, and it records that no message went.

A backup snapshot of the database is taken once a day and kept for thirty days, so a record we erase leaves those backups within that window rather than at the moment we erase it. Uploaded files and player photos live in object storage, which that backup does not cover, so no backup copy of those outlives their erasure.

A message you send to one of our addresses stands apart from any account: it is not part of what an account holds, so erasing an account does not remove it. We keep it, and our replies to it, for three years after the last message in its thread, and we keep longer any one of them that a law described above obliges us to keep.

The launch waitlist is not an account, and the address you leave for a launch notice is held by Clerk, our authentication provider, rather than in our database. Joining the waitlist means Clerk sends you a confirmation email, and at the launch we send the launch notice, which goes out as a Clerk invitation from the waitlist. The address is used for those two emails and for nothing else, and we send no marketing email. If you do not accept the invitation, we delete the invitation and the waitlist entry together within thirty days of that launch notice; the invitation ends when it is accepted, when we delete it, or when it expires. A pending entry we never sent a notice to is deleted within twelve months of the day it was left. You can ask us to delete your entry sooner by writing to privacy@scorvo.io, and we delete it then, without waiting for a notice or for those periods to run. An account you create from that invitation is a separate record, kept as the first paragraph of this section describes.

7. Your rights

You may ask us to give you a copy of your personal data, correct it, delete it, restrict or object to its processing, or provide it in a portable form. To exercise any of these, write to privacy@scorvo.io.

You can also download the data your account holds yourself, as one file, without writing to us. The file contains your account settings, the workspaces you administer, your club memberships and roles, the invitations you accepted and sent in the clubs you belong to, the changes you made in those clubs, the messages we sent or tried to send you, and a summary of your subscription, orders and credits. It does not contain other members' addresses, shared link addresses, card data, or the files you uploaded, and it does not contain roster rows or match results, because Scorvo keeps no link between an account and a player on a roster. You can download it once an hour.

Your right to object. Where we process your data on the basis of our legitimate interest, you may object to that processing at any time (GDPR Art. 21(1)). Two things in this policy rest on that basis. One is keeping the service secure, working, and improving. The other is the lines described in section 6 that say a deletion happened and on what day, kept after your account is erased; section 3 states the interest we rely on for it. To object to either, write to privacy@scorvo.io and say which one you mean. We then stop that processing unless we can demonstrate compelling legitimate grounds that override your interests, rights, and freedoms, or that we need it to establish, exercise, or defend legal claims — and if we rely on either of those, we will tell you which. The second one has a limit. That line exists so that we can answer a complaint about an erasure we already carried out, which is the defence-of-claims ground itself, and once your account is erased the line cannot be matched back to you from anything we hold — so for that record the honest answer to an objection is that we will explain the ground and the period rather than delete the line, and it goes on its own after ninety days either way.

Because a player is usually a record kept by an operator rather than an account holder, a player's request is normally handled through the operator who keeps that roster; we will help where we are the right party to act. To protect against disclosing data to the wrong person, we verify identity before we act on a request.

If you believe we have not handled your data properly, you can tell us at privacy@scorvo.io and we will answer with our reasons. If that does not settle it, you can take it to a supervisory authority — in Korea, the Personal Information Protection Commission or the Personal Information Dispute Mediation Committee; in the EU or UK, the authority where you live, where you work, or where you believe the problem happened. You can also go to court, and none of these routes depends on the others.

8. Cookies

We use only the cookies the service needs to work: the session cookies our authentication provider sets to keep you signed in, and a small preference cookie that remembers your language. Our visit measurement sets no cookie of its own. We do not use advertising or cross-site tracking cookies. A few preferences and unfinished drafts are held in your browser's own storage rather than on our servers — your theme, a score sheet you have not submitted, a tournament you have started setting up, the cards you set aside on Today for the day, and the name you picked on a shared session page — and none of that leaves your device by itself. One more is kept there and sent to us with the app's own requests when you open the screen that uses it: which assistant conversation a tab is on, so the assistant can show that conversation again.

9. Changes

If we change this policy, we update the date at the top. That date does not tell you what changed or how much: it is a day, so more than one change can sit behind it, and a correction to a single word moves it exactly as a larger change does.

Every earlier edition of this policy, with the days it was in effect, can be read from the link to earlier editions at the top of this page.

10. Contact

For anything in this policy, or to exercise a right, write to privacy@scorvo.io. For everything else, support@scorvo.io.