Privacy Policy

1. Who we are (data controller)

Osii (business registration 247-70-00655), represented by 이재원, 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. 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 is a real limit on what we hold and 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. 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 your account. 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.

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 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 says a deletion happened and on what day, which carries 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 — and we should be plain about its default, which is the full name the operator entered. An operator who does not want family names on that page turns that setting off, and the page then prints the given name alone. 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 an honest limit. What it prints is the given name held separately from the full one, so it hides nothing for a player who has no separate given name on file — a roster pasted in one name to a line does not, and for those players turning the setting off changes nothing at all.

A shared page carries the tournament: its programme, its results, and the standings. There is no public page of an individual player's statistics — no such page exists outside the club's own screens. Team line-ups 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 with no results at all is deleted outright.

5. Who else processes it (subprocessors)

We use a set of processors, each for a stated purpose: Clerk (account authentication), 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, and running the in-app assistant), 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).

Two of those are worth a sentence more. A turn with the assistant carries the context it needs in order to act on your club — the club's name and time zone, 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.

Some of these operate in the United States, so some processing happens outside your country. Where that is the case, transfers rely on the safeguards those providers offer, such as standard contractual clauses. We list only the processors we actually use today; if that set changes, this policy changes with it.

6. How long we keep it

We keep account and club data while the account is open. 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 it. 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 of our nightly sweeps after that — the day the message names, or the day after it. Beginning is not finishing: it runs in stages, it can take more than one night, and there are two things below that hold it. 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 of our nightly sweeps after the wait runs out — whether or not we were able to write to you. What it takes is the rest: the clubs you owned and everything in them — the roster, the results and statistics, the shared links, the files uploaded into them, the record of what your credits were spent on — and, wherever they were held, the conversations you had with the assistant. 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 of our nightly sweeps, 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, and what survives it is only what a law obliges us to keep. Two things do. 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 identity provider, the link to it becomes an internal reference, and the address and the wording on a delivery record are replaced. If the identity 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, and we would rather say so than let you assume otherwise. 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 our ten years are up, everything described in this section and the internal reference go with it.

Two things about those twenty-eight days are worth being exact about. 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 and raise it as a fault when it outlives the provider's own retry window.

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 sweep that starts it.

Not every account has all three. Which of them stay open to you depends on your sign-in, on whether the account screen still shows the control that stops it, 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 identity 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 — a deletion we recorded before we built the link does not get one — and for an account in that position a single one remains, whether or not you can still sign in: 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 and the account screen still shows the control that stops it, that control and a message to us are the two that remain.

• Where that message never reached you and the account screen does not show a control that stops it, a single one remains: a message to us before the erasure begins.

• 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 and the account screen still shows the control that stops it, that control and a message to us are the two that remain in the meantime.

• Where your sign-in was removed at the identity 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 identity 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 you help run but do not own can take you off its roster while the twenty-eight days run; stopping the deletion opens the clubs you own 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 account 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 we would rather name it than let "erasure is the default" imply it is gone with everything else. 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, and when that provider tells us somebody removed a sign-in there without ever having had anything of theirs here, 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 across our nightly sweeps, 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 sits here rather than on the message's own delivery record because that record is erased after thirty days and this one lasts ninety, so it is the only place the answer can still be given. 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. We should be exact about the limit of that. 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, and we would rather list the cases than let the silence be discovered. 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 nightly sweep, 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 — erasing one of those erases it once.

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.

Your right to object, stated on its own because the law asks us to put it in front of you separately. 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 says 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. We should be exact about the second one rather than leave you to discover it. 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 none of its own — it is the cookieless kind. 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, which assistant conversation a tab is on — and none of that leaves your device by itself.

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.

10. Contact

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