How we handle your data

Who is responsible for your data

One company is responsible for it, and you should know which. 深圳市水润天成实业有限公司 (Shenzhen Sunning Tension Industrial Co., Ltd.) is registered in the People's Republic of China at 512, Building A, Ruishangju, Guxing Community, Xixiang Street, Bao'an District, Shenzhen 518101, and trades as Your China Partner. It is the company you deal with, it decides why and how your enquiry is handled, and it is the one answerable for everything described here. In the words each regime uses: it is the personal information handler under China's Personal Information Protection Law, and it would be the controller under the GDPR.

No second company shares that responsibility. Until August 2026 this page named a Singapore affiliate here; it is no longer part of this business and it is named nowhere on this site. What has not changed is where the machines are. The site runs on Vercel Inc. in its Singapore region, and the database and the file storage run on Google Cloud (Google Asia Pacific Pte. Ltd.) in its asia-southeast1 region, with mail from a Singapore host. They run the hardware. They decide nothing about your data.

That distinction is worth stating precisely, because three regimes each have their own word for it. The Shenzhen company decides; the vendors act on its written instructions and on nothing else. That makes each of them an entrusted party under Article 21 of PIPL and a processor under the GDPR. Singapore's Personal Data Protection Act 2012 reaches the handling too, and removing the Singapore company did not change that: the Act's hook is the activity — collecting, using or disclosing personal data in Singapore — and not where a company is incorporated. Our processing happens there, so it applies. One arrangement, described three ways. It is deliberately not the other thing it could have been: your enquiry is not handed to an independent company that decides for itself what to do with it.

Because the deciding company is established in mainland China, PIPL is the primary regime for everything on this page rather than a footnote at the end of it. Two consequences follow and neither is cosmetic. Article 3 of PIPL reaches the handling of personal information undertaken within China, which is where our colleagues read your enquiry — so PIPL applies to your enquiry whether you are in Shenzhen, Stuttgart or São Paulo, and this page is written on that basis. And because every server we use sits outside China, providing your information abroad is not an edge case for us; it is the ordinary path, described in full in its own section below.

Using vendors does not move the responsibility, and neither does appointing anybody. Section 11(2) of Singapore's PDPA makes an organisation responsible for personal data in its possession or under its control, and section 11(6) says appointing a Data Protection Officer does not relieve it of a single obligation. That officer is designated under section 11(3) and their business contact information is published at the foot of this page, which is what section 11(5) requires. Two things it is not. It is not a GDPR Article 37 data protection officer — Article 37 turns on large-scale monitoring or large-scale special-category data, we do neither, and no such appointment has been made. And it is not a person in charge of personal information protection under Article 52 of PIPL: Article 52 bites only where a handler processes personal information above a volume prescribed by the national cyberspace department, and we are far below it. We publish the contact because the PDPA compels it and because you should be able to reach a person, not because Article 52 requires one.

What we collect

Three routes on this site collect personal data, and the enquiry form is only the first of them. This section used to say it was the only one, and that stopped being true the day accounts opened: registration collects, and so does a factory's application to be listed. Each has its own paragraphs below. What you type into it is what we store: your email address, which is required; your name and your company name, which are not; a description of the product; a quantity; any customisation you need; a free-text message; a target price and the currency it is in, which is always US dollars; a destination for the goods; a transport mode, which is one of sea, air, rail or unsure; and the date you need it by. Personal data also reaches us by one route that is not a form on this site at all — an intellectual property notice, sent by email or by post — and that route has its own section below.

If you create an account we store what the registration form asks for. Since 16 August 2026 that is more than it was, and all of it is required: your email address; your name; a company name, or the name of your shop if you sell online without a registered company; whether you are buying as a registered company at all; a link to your shop, asked only if you answered that you have no company; which of eleven kinds of buyer you are; what you sell today, in your own words; and the product categories you want to source, which is one main category and whatever you tick under it. Alongside it we store an scrypt hash of your password. The password itself is never stored and cannot be recovered from the hash; that is why a forgotten one is replaced rather than retrieved. Accounts created before that date were never asked these questions, hold none of these answers, and nothing has been filled in for them from anywhere else. If you sign in with Google or LinkedIn instead, we store the stable subject identifier that provider gives us and the address it asserted, so that signing in again lands you in the same account rather than a second empty one — and we ask you the same questions above on our own page, because the provider does not answer them. Neither provider tells us anything else — we asked them for the three standard claims and nothing more, so no company, no job title and no contact list reaches us from either.

Signing in writes two operational records. A session row holds a random lookup key, a hash of the matching secret, which kind of account it is, the two times at which it dies, a truncated form of your IP address and a hash of your browser's user-agent string. A sign-in log records each attempt on your account — the outcome, the method, and the same truncated address. The address is truncated to the network and never the host, which is enough to show a sign-in from an unfamiliar place and not enough to be a location history. The log records failures as well as successes, because “was this account broken into” cannot be answered afterwards without them, and it is the first question anyone asks on the day it matters.

Two more things accumulate as you use an account: the products and searches you choose to save, and a record of each Gold or Bronze factory whose registered company name you asked to see. That last one exists because the disclosure is the point of holding an account, and a disclosure we made about a third party is not something we should be able to make disappear afterwards.

Four things are recorded without you typing them. The language you are reading in, stored as en or zh. The page the enquiry came from. The user-agent string your browser sends. And a salted SHA-256 hash of your IP address — the raw IP is never written to storage at all, and where no salt is configured the column is simply left empty. The hash exists for one purpose: a rate limit of five enquiries an hour from the same hashed address. Where there is no salt there is no hash, and in that state the limit does not run at all. We will not call the hash anonymous either. It sits in the same row as your email address, so you remain identifiable from it together with what else we hold; PIPL would call that de-identification rather than anonymisation, and the distinction is the whole difference between a true sentence and a flattering one.

We do not ask which country you are in and we do not work it out. Destination is where the goods go, not where you are. Once an enquiry arrives we add our own working fields to the row — its status, which member of staff owns it, when we first replied, and our internal notes — and a separate log records each email we send about it: the address, the type, whether it was delivered, the provider's message ID and any error.

Your email address is the only thing we genuinely need, and it is required for one reason: without it we cannot reply. That is not a statutory or contractual requirement, and nothing worse happens if you withhold it than that no answer can reach you. Everything else is optional and only makes the quote better. We take the details as you give them — we have no way to verify them, and if any of them are wrong, the correction route is below.

What we never collect

Buyer accounts are in service, so the honest version of this section is what an account still does not collect. We hold an scrypt hash of your password and never the password. Since 2026-08-16 the buyer registration form asks for a WhatsApp number and an office telephone number, and offers a Telegram handle you may leave blank. It asks for no personal address, no date of birth, no security question and no identity document, and there is no field for any of them. The WhatsApp number is also one of the three things you can sign in with, alongside your username and your email address; the office number is a contact and never a credential. These three are held for our own staff to reach you and are never shown to a factory. A factory portal login asks for a name and a mobile number, because a supplier reviewer has to be able to call the company back about its own application. We hold no payment instrument for anybody, of any kind.

The enquiry form has no upload control, so we hold no drawings, certificates or documents from buyers. There is no checkout, no escrow and no payment, so we hold no card number, no bank account and no financial account details — which Article 28 of PIPL would classify as sensitive personal information. Where an enquiry becomes an order, the invoicing and the payment happen off this website entirely. The form asks for no telephone number, no personal address and no identity document. Two other routes on this site do ask for more, and each has its own section below: an intellectual property notice asks for all three, and a factory applying to be listed uploads its own company documents — its business licence, and any certification it claims. Neither route is the enquiry form. A buyer still cannot attach a file to anything on this site. Since 2026-08-23 what a factory files about a certificate — the kind of certificate it is and the name the factory gave it — becomes visible to a signed-in buyer as soon as the upload has been confirmed, with nobody here reading it first. The document itself is not displayed and is never served publicly, and the business licence is not shown to a buyer at all.

We receive no personal data about you from anyone else. No data broker, no enrichment service, no verification vendor, no third party of any kind feeds this table. Please keep health, religious, biometric and financial details out of the free-text fields — we do not ask for them, we have no lawful ground to hold them, and if they arrive our staff take them out of the record.

There are still no automated decisions with a legal or similarly significant effect. Nothing here scores, ranks or profiles you; listings are written by our own staff and every visitor sees the same prices. Some factories pay for placement and for having their registered name shown publicly, but that is one commercial decision applied identically to every visitor — it is not personalisation, and it cannot be about you, because we know nothing about you. What is automatic is a set of limits: five enquiries an hour from one hashed address, and a cap on how many times in a quarter of an hour a password may be tried against one account or one address. When a limit trips it refuses the next attempt for a period and then releases by itself. It decides nothing about you and no human reviews it, because there is nothing to review — waiting is the whole remedy. One further thing is automatic, and unlike those limits it reaches you rather than merely refusing something: where we quoted against your enquiry and it then went quiet, we write to you once at fourteen days, once at thirty and once at sixty, with a single question — did it become an order? Two links, no login, and no tracking pixel of any kind. No reply is a complete answer and is recorded as no reply. We ask you rather than the factory because the factory is the party we invoice, so it is the one party with a reason to stay quiet. It scores nothing, ranks nothing and decides nothing about you, and where a record is frozen under the holds described below we do not write at all.

If you send us an intellectual property notice

This is one of the two routes by which personal data reaches us other than the enquiry form: a notice sent under our intellectual property policy. The other is the company documents a factory uploads with its application, described further down. That page asks for a different set of categories entirely — your name and your company, its registration number and country of incorporation, the rights owner's name as it appears on the certificate, proof of who you are (a business registration extract for a company, an identity document for an individual), an agent's written authority where there is one, the registration or other proof of the right, your evidence, a postal address, a telephone number, and an email address a person actually reads. Some of that is personal data about you. Some of it is personal data about other people, and we ask you to send no more of that than the notice needs.

We hold it for three purposes and no others: to assess the notice, to act on it, and to keep the record of what we decided and why. There is no marketing list on this site to add you to. Under the PDPA the basis is consent, deemed under section 15(1), because you provide the data voluntarily, for a purpose you chose, in circumstances where it is reasonable that you would provide it. Where a notice comes from someone in mainland China, consent under PIPL does the same work, and everything this page says about withdrawal applies — with the obvious consequence that withdrawing consent to a notice means we stop acting on the notice.

Your notice is read by our own staff in Shenzhen, the same place an enquiry is read. It then goes one step further than anything else described on this page. Within two working days of acting on a notice, we send the notice itself — including who sent it — to the factory that makes the product, because nobody can answer an accusation they cannot see. That factory is a separate company in mainland China and a recipient outside YCP: the closed list of recipients below is about enquiry data and does not cover this, which is why the disclosure is stated here as well. If there is a specific reason a piece of your contact detail should not travel, say so in the notice; we hold it back and act as the channel instead. Both the disclosure and the hold-back are set out in full on the intellectual property policy, and they are repeated here because this is the point at which you decide what to send.

We keep the notice, your identity and authority documents, the evidence and our decision for six years from the date of the decision, then delete the file. That is the period stated on the intellectual property policy and it is set the way every other period on this page is set: long enough to cover the time in which a claim about the decision could still be brought, and no longer. The rest of this page applies to that file as it applies to an enquiry — how to make a request, what you can ask for, what happens if something goes wrong — with one difference worth naming. That file does contain identity documents, so if you ask us about it we may ask you to identify yourself consistently with what you already sent, which is not something we do for an enquiry row.

Why we hold it, and the law that allows it

A closed list for enquiry data, because a vague one is not worth publishing. We hold your enquiry to read and answer it; to source and quote against it, which means our Shenzhen staff working the request; to keep the form usable by rate-limiting abuse; to keep a record of what you were shown when you consented; and, where an enquiry becomes an order, for our own accounting and legal records. That is all of it. The intellectual property notice file has its own purposes, stated in its own section above. We send no marketing email, run no profiling, and sell nothing to anyone.

PIPL comes first now, because the company deciding all of this is in China. Article 13 lists the bases on which personal information may be handled, and consent is the first of them — that is ours, given by ticking the box on the form. Two things about that list matter enough to spell out. It contains no legitimate-interests basis: unlike the GDPR, Chinese law simply does not offer one, so there is no quieter route we could have taken instead of asking you. And the contract basis at Article 13(2) covers handling necessary for a contract to which you personally are a party — which is usually not the case when you are enquiring on behalf of the company that employs you. We could have leaned on it and did not, because it would not bear weight for most of the people who use this form. Consent does the work, and the section below on cross-border transfers explains what follows from that choice.

Under Singapore's PDPA the basis is your consent as well, under sections 13 and 14. Your name, company and work email are business contact information, which section 4(5) takes outside most of the Act — but the product description, the price, the destination, your message, the user-agent string and the hashed IP are not, and we have no way of verifying that a self-declared work address really is one. So we treat the whole row as personal data and rely on consent for all of it, rather than leaning on a carve-out that only covers part. Section 14(2) forbids requiring consent to more than is reasonable, so the tick covers handling your enquiry and nothing else. We do not invoke the Act's legitimate-interests exception for the rate limit either: that exception carries its own documented-assessment preconditions, and the cleaner answer is that abuse prevention sits inside the purposes you were told about.

The GDPR is the third regime, and the section on the European Union below sets out why we say it does not reach this site. We state our position under it regardless, as a matter of practice rather than as a concession: the basis we would apply is Article 6(1)(f), legitimate interests — not consent, despite the tick box. Those interests are specific, because Article 13(1)(d) requires them to be: answering a business enquiry you sent us, identifying suitable factories and preparing a quote, keeping the form from being flooded, and holding evidence of what we told you. Where an enquirer is personally the prospective counterparty rather than an employee of a buying company, Article 6(1)(b) would also cover steps taken at your request before a contract.

The exact words you agreed to

The consent box is never pre-ticked and never bundled with anything else. Consent is checked three separate times before anything is accepted: in the browser, again in the server action that refuses the submission without it, and once more by the database — an enquiry cannot be stored at all unless both consents and both wordings are present, a factory login that can sign in cannot exist without both consents, and a buyer account that records one of them cannot be missing the other or the words that went with it. The catalogue itself reads without consenting to a word: every product page, every category, every article, every search. Five things ask you to agree. Sending an enquiry, posting a request for quotation, opening a buyer account, registering a factory, and accepting an invitation to a factory’s portal. Each of them asks twice, because consent to send your details outside mainland China is taken separately from consent to handle them at all. The request for quotation asks a third time, and that one is optional — the last paragraph of this section is about it.

There is not one wording but three pairs of them, because there are three different things you might have agreed to, and this is the section that publishes all of them. The enquiry form shows “I agree that YCP may store and use these details to respond to my enquiry.” and, as a separate tick, “I agree that my details may be sent outside mainland China — to the Singapore hosting, database and mail providers listed in the privacy policy — so that this enquiry can be received, stored and answered.” The account and factory forms — and the page where a colleague accepts an invitation — show “I agree that YCP may store and use these details to run my account and answer my enquiries.” and, again separately, “I agree that my details may be sent outside mainland China — to the Singapore hosting, database and mail providers listed in the privacy policy — so that this account can exist and be used at all.” The request-for-quotation form shows a third pair, because it asks for something the other two do not — a brief that goes in front of factories: “I agree that YCP may hold this brief and the contact information on it, use them to source and quote this job, and put the brief in front of factories with my identity removed.” and, as a separate tick, “I agree that this brief, and the contact information on it, may leave mainland China and sit on servers in Singapore — the hosting, database and mail providers named in the privacy policy — because that is where this form delivers, and no copy of it stays behind in China.” Whichever pair you saw, we store those sentences verbatim in your row, next to the moment you ticked them. If we change the wording later, your row keeps the wording you actually saw.

One tick on this site is optional, and it is the only one. On the second screen of the request-for-quotation form we ask: “I agree that YCP may give my company name, my website and my store link to a factory that has already quoted on this brief, and to no one else.” Leaving it unticked does not stop the form, does not delay the brief and costs you nothing — the brief reaches factories with your identity removed either way. It is asked separately because it is a different act: the two above are consent to us handling your details, and this one is consent to a named third party receiving them. And it is not enough on its own. Your name reaches a factory only when this tick is present AND that factory has spent a finite credit to put a real quote in front of you. A membership tier never buys it, at any price. You can tick it later, from your own brief page, long after the brief is live — and if you never do, no factory ever learns who you are.

That is the whole point of doing it this way. A company that stores a yes/no flag can tell you that you consented. We can tell you what you consented to. And if we ever change the purpose, the method or the categories of data we collect, Article 14 of PIPL requires fresh consent — the old tick does not stretch to cover new uses, and the stored sentence is how you would hold us to that.

Who else sees it — and who never does

No factory ever sees your enquiry. What a factory can be shown is a separate, de-identified brief we write from it: what you want made, how many, which country it is going to, your target price and your timeline. Your name, your company, your email address and your city are not withheld from that brief — they are absent from it. There is no supplier_id column on the enquiry table and there are no name, company, email or city columns on the brief, so neither object has anywhere to put what the other holds. That is not a promise we are asking you to take on trust; it is a shape, and the factory-facing side of the site connects to our database as an account that the server itself refuses to let read your enquiry. At most ten factories can ever open one brief, and that cap exists as much to bound how many companies see anything about you as to keep the replies comparable. Your contact details are a separate act. They reach a factory only when a named colleague of ours releases them for one brief and one factory, giving a reason we record, and only where three things are already true: you agreed at the outset that a quoting factory could be given them, that factory has signed a data-protection undertaking with us, and it has actually submitted a quotation rather than merely read the brief. No membership tier discloses them, at any price. You can see who has been given what, and when, on the page where you compare the quotes — and you can tell us to withdraw it.

Who does see it: our own staff, in Shenzhen. Three service providers handle it in the course of running the site, and none of them has any purpose of its own for it — Vercel, which hosts the site with its functions pinned to Singapore; Google Cloud SQL for MySQL, which holds the database in the asia-southeast1 region in Singapore; and our own mailbox at Exabytes, a Singapore host, which carries the enquiry email. Vercel and Google Cloud are used on their published terms, which include the data processing terms each of them publishes for customers in our position. The mail host is a shared hosting account carrying our own mailboxes, and we describe it as exactly that rather than imply a negotiated instrument we would then have to produce. What does not depend on any of that paperwork is section 4(3) of the PDPA: we stay as responsible for what a service provider does with your data as if we had done it ourselves.

Nothing here is sold, published or made public, and there is no surface on this site that could display it. If this business were ever sold or reorganised, you would be told who was taking over the record before it moved. That closed list is the list for enquiry data. It is not the list for an intellectual property notice, which has one further recipient — the factory named in it — set out in its own section above.

We would also have to hand data over where a court or a competent authority lawfully required it. In mainland China that runs through the Shenzhen company, where Article 25 of China's E-Commerce Law obliges an operator to produce data to a competent authority that asks for it. In Singapore it runs through the three service providers named above, because they are the parties that physically hold the data there and they, not us, are who a Singapore order would be served on. We would rather write that plainly than write a sentence promising we never share anything with anyone, which would not be true.

One further recipient exists, and only when somebody orders it. Since 2026-08-23 a certificate a factory files is displayed without anyone here checking whether it is genuine, and a buyer or the factory itself may order that check from us as a paid service. Performing it means putting that certificate in front of the body that issued it, or in front of an inspection company acting for us — a disclosure to a recipient outside the list above, for a purpose that exists only because it was ordered. It happens on that order alone, it covers only the document named in the order, and the only personal data it can carry is what is printed on the certificate itself, typically the name of the factory's legal representative, which is the same data described in the section on what we collect. Your enquiry is no part of it. Whoever ordered the check is told who we went to.

Data leaving Singapore

The database is in Singapore and the site runs in Singapore. That does not mean your data stays here. Our sourcing staff in Shenzhen open your enquiry to work on it, and under section 26 of the PDPA the transfer is that access path — not the location of the disk. A policy that markets Singapore data residency while staying quiet about Shenzhen access is telling you only the half that sounds better.

There is one company now, so this is not a transfer between two group members — it is one organisation reaching its own records from another country. That does not put it outside the rule. Regulation 10 of the Personal Data Protection Regulations 2021 requires, before personal data leaves Singapore, that it be protected to a standard comparable to the Act, and regulation 11(2) requires the instrument relied on to do two things: impose that standard, and name the countries the data may go to. Ours names the People's Republic of China, and it binds our Shenzhen staff by contract and by internal policy rather than by an inter-company agreement that no longer exists. Off-the-shelf vendor agreements routinely do the first and forget the second.

We do not rest this transfer on your consent, and that is deliberate. Regulation 10 offers consent as an alternative route, but regulation 10(3) says you have not consented unless you were first given a written summary of how the data would be protected in that country. The sentence you actually ticked says nothing about protection standards in China. It would be easy to point at the tick box and call it consent to the transfer. It would also be wrong, so the transfer stands on the written agreement instead, which is the route that does not depend on you having agreed to something you were never shown.

Read this section together with the next one and the shape becomes clear. Singapore is where your data physically sits; China is where the company that decides about it sits. Each direction has its own rule, and we have not merged them into one reassuring sentence.

Data leaving mainland China

Direction matters more than most policies admit, and on this site it runs the opposite way to the obvious guess. The company that decides what happens to your enquiry is established in mainland China, but not one of the machines it uses is. The site, the database and the mailbox are all in Singapore. So from the moment you press send, your information is being made available outside China by a Chinese handler — which means Chapter III of PIPL, the cross-border rules at Articles 38 to 43, is not an edge case that catches the occasional Chinese enquirer. It is the ordinary path for every enquiry this site receives.

Article 38 requires one of several routes before personal information is provided abroad, and ours is the exemption in the CAC's 2024 Provisions on promoting and regulating cross-border data flows: we provide the personal information of far fewer than 100,000 individuals abroad in a calendar year, we are not a critical information infrastructure operator, and we hold no important data and no sensitive personal information. We count that figure, and the count resets on 1 January. If we ever crossed it the route would change to a standard contract or a certification, and this page would change with it. We are not claiming a permanent exemption.

Article 39 requires two separate things, and it is worth reading it as two rather than one because they are excused on different terms. The first is notice: before information is provided outside the country we must give you the overseas recipient's name and contact details, the purpose and method of processing, the categories of personal information involved, and the way and the procedure by which you exercise your PIPL rights against that recipient. That duty does not depend on which basis we rely on, so nothing we could have chosen would have removed it. The second is your separate consent to the provision itself.

Here is that notice. The overseas recipients are Vercel Inc., which runs the site in its Singapore region, and Google Cloud (Google Asia Pacific Pte. Ltd.), which runs the managed MySQL database and the file storage in its asia-southeast1 region, together with the Singapore host that sends our mail. All of them are reachable through us, at the address at the foot of this page. The purpose is receiving, storing and answering your enquiry. The method is a managed database, serverless functions and mail, all in Singapore. They are overseas recipients and not merely our vendors. That is not us being cautious: the standard contract the Cyberspace Administration of China publishes for cross-border transfers defines an overseas recipient as any organisation outside the country that receives personal information from the handler, and says nothing about whether it decides its own purposes. A company that only follows our instructions still receives your data, so we list it rather than hiding it behind the word supplier. The categories are the fields listed above, and every right described on this page can be exercised against any of these recipients through us, at that same address.

On the separate consent, we want to be accurate about why we ask for it, because an earlier version of this page was not. It is sometimes said that being exempt from the Article 38 mechanisms excuses neither the notice nor the consent. That is not quite what the regulator has said. The position set out in the second edition of the CAC's filing guidelines is narrower and more useful: separate consent for a cross-border transfer is required where consent is the basis being relied on, and is not required where the handling rests instead on one of the other bases in Article 13. We rely on consent — for the reasons given in the section on legal bases above — so the requirement applies to us. Same answer, different reason, and the reason is the part a page like this owes you.

What the form does, stated plainly so you can measure it against that requirement. It takes a separate cross-border consent, on its own, in addition to the consent to handle your enquiry at all. Neither box is ever pre-ticked, and neither is folded into an acceptance of terms. The exact wording shown on screen at the moment you tick is stored verbatim against your enquiry, so what any individual agreed to is always recoverable, word for word, whatever this page says later. And that consent can be withdrawn at any time by writing to the address at the foot of this page — the section on stopping us sets out exactly what happens when you do.

If you are in the European Union

Article 3(2) reaches a company with no establishment in the Union in two situations, and they are worth taking one at a time. We are a Chinese company, incorporated and operating in Shenzhen, with no establishment anywhere in the Union. The first situation, Article 3(2)(a), catches the offering of goods or services to people in the Union, and what it turns on is whether we direct ourselves at a Union market — not whether someone in the Union can reach the site. Since 2026-08-16 the buyer registration form does carry a country dropdown, and this section is written to be accurate about it. It lists every inhabited country and territory in the world in one flat list; it does not enumerate Member States as a group, offer a Union option, or treat any Member State differently from anywhere else. Nothing on this site is priced, shipped, translated or targeted by what you choose there. The enquiry form still has no country field at all: destination is a free-text box for where the goods go, and outside that one dropdown we neither ask nor infer where you are. We offer no delivery arrangement of any kind — no freight quote, no shipping calculator, no list of countries served and no Union delivery option — because nothing on this site sells or ships anything. Prices are quoted in US dollars and in no other currency. The site exists in exactly two languages, English and Simplified Chinese, which are the working languages of sourcing out of China rather than the language of a Member State market we are courting; there is no version of this site in any other language of the Union, no Union address, no Union telephone number, and no Member State domain.

The second situation, Article 3(2)(b), catches the monitoring of behaviour taking place in the Union. We do not monitor the behaviour of anyone in the Union. Outside Europe we count visits with Google Analytics, set out in the cookie section below; in the EEA, the UK and Switzerland it sets no cookie and keeps no identifier, so no visit there is joined to another visit or to a person, and no profile is built. There is no tag manager, no pixel, no advertising network and no cross-site tracking. Neither situation in Article 3(2) is met, so the Regulation does not apply to this site, and Article 27 — which is triggered by Article 3(2) and by nothing else — does not require us to appoint a representative in the Union. We have not appointed one, and you will not find an EU address on this page, because inventing one would be false and would pull us under Article 3(1) entirely. What follows we apply as a matter of practice, because it is a sound way to handle data and because we would rather be measured against it than not. Nothing in it concedes that the Regulation applies to us.

On that footing: sending us the form would not be a Chapter V transfer in any event. You are the source of your own data, not an exporter of it, so no safeguard is needed for that leg, and you will not find a line here asking you to consent to your data being sent to Singapore. The transfer that would matter is the next one: Singapore to our staff in Shenzhen. The Commission has issued no adequacy decision for Singapore and none for China. We apply the Commission's standard contractual clauses in their controller-to-processor form, which is the module that matches what actually happens — Shenzhen acts on our documented instructions and never sets its own purposes for buyer data. Ask and we will send you a copy.

Those clauses require us to consider what the law of the destination country could do to them, and for the People's Republic of China that question cannot honestly be answered "no risk" by assertion. What we can say is what the arrangement is: access is limited to named sourcing staff, no bulk export of the enquiry table happens, and the data itself is a business enquiry rather than anything the categories of concern are usually about.

The same question arises for the infrastructure. Vercel, Google Cloud SQL and our mail host all sit in Singapore, which is likewise a third country with no adequacy decision. Vercel and Google Cloud publish data processing terms for customers in our position, and those are the terms the accounts run on. The mail host is a shared hosting account carrying our own mailboxes, and we describe it that way here for the same reason we describe it that way above.

How long we keep it

Section 25 of the PDPA is a positive duty: we must stop holding a document containing personal data once the purpose it was collected for is no longer served and there is no legal or business reason to keep it. PIPL Article 19 puts it as the shortest period necessary, and Article 47 goes further — deletion is something we owe you on our own initiative once the purpose is spent, not only when you ask. Our retention policy fixes those points in time.

An enquiry that does not lead to an order is kept for 24 months from the last message exchanged about it. The email delivery log is kept for 12 months. Where an enquiry becomes an order, two different clocks start and it is worth separating them rather than quoting you the shorter one. The accounting records themselves — the invoice and the vouchers behind it — are kept for thirty years from the first day after the accounting year ends, because China's Measures for the Administration of Accounting Archives set that as the minimum for a Shenzhen company and it is not a period we are free to shorten. The enquiry does not inherit it. The enquiry stays with the order paperwork for five years from the end of the financial year it was invoiced in and is then deleted, because Article 19 of PIPL requires the shortest period that still serves the purpose, and thirty years of a buyer's messages serves none of ours. An intellectual property notice file is kept for six years from the date of our decision, for the reason given in its own section. Each period is set the same way: how long the purpose can still be served, plus the shortest tail our own legal and accounting records need. When a period expires the record is deleted — not archived, not moved somewhere quieter.

An account is kept while you hold it and is removed when you ask us to close it, along with the products and searches saved under it. Two records attached to it have their own periods. A session record dies when it expires or when you sign out, and is cleared with the rest. The sign-in log is kept for twelve months: a shorter period would leave “was this account broken into” unanswerable across exactly the window in which it is normally asked. The record of which factory names you asked to see is kept for as long as the account, for the reason given above.

Deletion is done by hand, by the Data Protection Officer, working through the table against this schedule. A nightly job does run, and it is worth saying exactly what it does: it counts the records that have passed their period, writes the count down, and stops. It has no ability to delete — that is a property of how it is built, not a policy we could quietly relax. Every deletion on this site is a person reading that count and acting on it. We would rather tell you a job runs and cannot delete than let you assume nothing runs at all.

Two things override the schedule, and both have an end date. If we have refused an access request, section 22A of the PDPA requires us to preserve that data rather than delete it, for at least thirty days after the refusal and longer while a review or appeal is running — that is a preservation period, and it is not the same thirty days as the one in the rights section below. And if a record is needed for a legal claim, we keep it until the claim is resolved. Where a record is frozen for either reason, we do nothing with it except store it and keep it secure, which is exactly what Article 47 of PIPL requires in that situation.

What protects it

Specifics, rather than adjectives, because section 24 of the PDPA and Article 51 of PIPL both ask what we actually did. The database is reached through the Cloud SQL connector using mutual TLS with short-lived certificates; the list of authorised networks is empty and 0.0.0.0/0 is never used. Your raw IP address is never written to storage. Access is limited to named YCP staff, and our Shenzhen colleagues work to this policy — section 12(c) of the PDPA requires us to tell our own people what the rules are, and the sourcing team is the part of our own people this matters most for.

There is a credential now, so here is what actually protects it. A password is stored as an scrypt hash with its own random salt, and the cost parameters are stored beside each hash so that raising them later does not lock out anyone who has not signed in since. A session is not a token that carries its own claims: the cookie is a random lookup key plus a random secret, only a hash of the secret is stored, and the comparison is done in constant time. That design costs a database read on every signed-in request and buys the one thing a self-contained token cannot give — if we block an account, or you sign out, it stops working on the very next request rather than whenever a token would have expired. Password-reset and email-confirmation links are stored hashed and work once; setting a new password ends every session on every device, which is the point of resetting one.

The rest of the security story is still about what is not there. The enquiry form has no upload control, so no buyer documents sit in the database to leak. Documents do reach us by two routes, both described above: an intellectual property notice, and the company documents a factory uploads with its own application. Neither is stored in the database, and neither is ever public. Those files sit in a private storage bucket with public access prevention enforced on it, and they are read back only through a link that is signed for one named file, lasts minutes, and stops working when it expires. The description and the document are two different things, and only one of them is shown: what a signed-in buyer sees of a factory's certificate is what kind it is and the name the factory gave it, and the file behind it is reached only through one of those signed links, never from a public page. There are no card numbers, because we take no payment. The only outside scripts are Google Analytics and Google reCAPTCHA, both described in the cookie section below. Most of what goes wrong at companies our size goes wrong through something we deliberately never built.

If something goes wrong

Part 6A of the PDPA makes breach notification mandatory and we will comply with it. If we have reason to believe a breach has occurred we assess it in a reasonable and expeditious manner — there is no 30-day statutory assessment clock, whatever templates say. If we assess a breach as notifiable, we notify the Personal Data Protection Commission as soon as practicable and in any case no later than 3 calendar days after the day we make that assessment. Calendar days, and counted from the assessment, not from the incident.

Affected individuals are told where the breach is likely to cause significant harm, on or after we notify the Commission and never before. A breach is separately notifiable on scale alone at 500 individuals, and one notifiable only on scale goes to the Commission without individual notice being automatic. Harm is the independent limb, and one person is enough to trigger it. The enquiry table holds none of the categories the regulations deem significantly harmful — no identification numbers, no bank or card details, no credentials, no health data — which is worth saying plainly, and is not the same as saying a breach here could never be notifiable. An intellectual property notice file is the exception on this page: it can contain an identity document, so it does not get the benefit of that sentence. The harm limb does not care what our schema looks like in any event.

One design decision earns its keep here. Because the raw IP is never stored and only a salted hash exists, a measure that was in place long before any incident, the data that could leak is already less than it might have been. The Act treats a pre-existing technical measure of that kind as relevant to whether individuals need telling; it does not affect the duty to tell the Commission.

Article 57 of PIPL runs alongside, on its own clock, and triggers on information that may have been leaked as well as information that certainly was. Its notice has to state the categories involved, the cause and the likely harm; what we have done and what you can do; and how to reach us. Where we apply the GDPR position described above, there is a parallel duty to the relevant supervisory authority. None of these three waits for the others.

Making a request

Write to the Data Protection Officer at the address at the foot of this page. Say what you want, and send it from the email address on the enquiry — for enquiry data that is normally all we need to know it is you, and we will not ask for a passport scan to release one row about a business enquiry. Collecting an identity document to answer a request about a record that contains no identity document would be the wrong trade. A request about an intellectual property notice is the one case where we may ask for more, because that file does contain identity documents and we have to be sure we are handing them back to the person who sent them.

None of this costs anything. Regulation 7 of the PDP Regulations 2021 would let us charge a reasonable fee for access, and we do not; there is no power to charge for a correction at all, and under the GDPR exercising a right is free.

On timing, we answer as soon as we reasonably can, and the outer limits differ by regime. Under the PDPA the standard is "as soon as reasonably possible" for access and "as soon as practicable" for correction — not a flat thirty days; if we cannot answer within thirty days, regulation 5 requires us to write to you inside those thirty days and tell you when the answer is coming. Under the GDPR we answer within one month, and where a request is genuinely complex we may take two more, but we have to tell you that and tell you why inside the first month. Under PIPL the standard is that we answer in a timely way, with no fixed statutory period; we commit to 30 days so the promise is testable. Where we decline a request we say why, within the same window, rather than going quiet.

Article 24 of China's E-Commerce Law asks for the method and the procedure, not merely the right, so here they are in one sentence: write to the address below, from the address on your enquiry or on your account, say what you want done, and we do it or explain why. If you hold an account, closing it is one of the things you can ask for and it is done the same way — Article 24 requires that closing an account be no harder than opening one, and writing one line to the address below is not harder than filling in the form. Closing an account does not delete an enquiry we still have to keep for an order or for our own accounting records; the retention section above says exactly how long those are held and why.

What you can actually ask for

Under the PDPA you may ask for a copy of your personal data and — the limb most policies drop — for a description of how it has been used or disclosed in the year before you asked. For us the honest answer will normally include access by our own staff in Shenzhen. You may ask us to correct an error, which we do as soon as practicable and pass on to anyone we disclosed the data to in the previous year, which again means Shenzhen. There are narrow statutory grounds on which access can be refused or part of a record withheld; if we withhold anything we will tell you that we have, rather than sending a partial answer that looks complete. And Singapore has no right of erasure, no right to object and no portability right in force — we would rather say so than list rights we are not obliged to give you.

Under the GDPR position we apply as a matter of practice, you also have rectification, erasure, restriction and objection, and an access request carries the right to be told about the safeguards covering the transfer to China. Portability is the right most policies over-promise: Article 20 applies only where the basis was consent or a contract with you personally, so it does not arise where we rely on legitimate interests, and we will not pretend otherwise. If we decline, we tell you why and tell you that you may complain to a supervisory authority and go to court.

Under PIPL you may consult and copy your information, ask for correction or supplementation (we verify first, then correct), ask for deletion, withdraw consent, and — a right with no European equivalent — require us to explain our processing rules, which is a right about the rules rather than about the data. Article 45(3) portability depends on conditions the CAC has never issued, so there is no statutory mechanism to promise; ask and we will export your row anyway. Close relatives of someone who has died may exercise access, copy, correction and deletion for their own lawful interests, unless the person arranged otherwise in their lifetime.

If you want us to stop

You may withdraw your consent at any time, and we will not put anything in the way of it. Write to the Data Protection Officer. Section 16 of the PDPA requires us to tell you the consequence, so here it is: we stop working on your enquiry and stop replying to it. Withdrawal is not retrospective — it does not unmake what we lawfully did beforehand — and under Article 15 of PIPL it takes effect from the moment you ask. Under Article 47 withdrawal is also one of the events that puts us under a duty to delete.

When you withdraw, the instruction has to reach everyone who touches the record. Section 16(4) of the PDPA requires us to make our service providers and our own people stop as well — which for us means the sourcing team in Shenzhen, not only the database in Singapore.

Your right to object

This one gets its own heading because the GDPR insists on it, and it keeps the heading whether or not the Regulation reaches you. Article 21(4) requires the right to object to be brought to your attention explicitly and presented separately from everything else, and a bullet buried in a list of six rights does not do that.

Where we apply Article 6(1)(f), legitimate interests, you have the right to object to that processing at any time on grounds relating to your particular situation. It is not the same thing as withdrawing consent, and it does not depend on consent having been given. If you object, we stop, unless we can demonstrate compelling legitimate grounds that override your interests, rights and freedoms, or unless we need the record for a legal claim. The burden of showing that sits on us, not on you.

Article 44 of PIPL gives a broader right again, and without the balancing gate: you may restrict or refuse our processing of your personal information. Write to the same address.

Cookies: ours, and Google Analytics outside Europe and mainland China

Of our own cookies, there is exactly one before you sign in, and it is ycp_locale. It holds one of two values, en or zh. It is set when you choose a language, its path is /, its SameSite setting is Lax, it is marked Secure over https, and it lasts one year.

Signing in adds a session cookie, and which one depends on which door you came through: __Host-ycp_bs for a buyer, __Host-ycp_ss for a factory, __Host-ycp_ts for our own staff. They are separate names on purpose, so that a session issued at one door cannot be presented at another. Each holds a random lookup key and a random secret, is marked HttpOnly and Secure, and is not readable by any script on the page. Alongside it sits __Host-ycp_who, which holds one word — buyer, supplier or staff — and is deliberately readable by the page, because the header has to know whether to say “Sign in” or “My account” without making every page on this site uncacheable. It grants nothing: forging it changes a link label and no more, and every protected page checks the real session against the database anyway. If you use Google or LinkedIn to sign in, one further cookie, __Host-ycp_oa, exists for the ten minutes of that round trip and is deleted the moment you come back.

Outside Europe and mainland China we use Google Analytics to count visits and see which pages help buyers. It sets two cookies, _ga and _ga_QEZYEKWLEB, each lasting up to two years, and records the pages you open, the words you type into the site search, how you arrived, your approximate location (worked out from your IP address, which Google Analytics does not store), your device and browser, and one event, generate_lead, when an enquiry or RFQ goes through — never what you wrote in it. Google processes this for us under its data processing terms, on servers that may be outside your country, including in the United States, and keeps event-level data for two months and user-level data for fourteen. Google Signals is off and ads personalisation is off; the link to our Google Ads account only tells us which ads led to an enquiry. Every form on this site also runs Google reCAPTCHA when you submit it, to tell people from bots: Google receives your IP address and browser details for that one check, and we receive a score. To opt out of analytics, block cookies for this site or use Google's opt-out add-on at tools.google.com/dlpage/gaoptout.

In the EEA, the UK, Switzerland and mainland China it works differently. A browser set to a time zone there never loads Google Analytics, and for anyone Google places in those countries the tag runs with storage switched off: no cookie is set and no identifier is kept, so at most an anonymous count of the page view reaches Google, linked to nobody and to no other visit. That is why there is still no consent banner: our own cookies are strictly necessary for what you asked for, which the ePrivacy Directive exempts from consent, and the analytics cookies are never set where that Directive applies. Singapore has no separate cookie statute, and PIPL has no cookie-consent article.

Children

This is a business-to-business service. The enquiry form asks for a company name and a work email because we expect to be dealing with someone doing their job. We do not aim any part of this site at children and we do not knowingly collect personal data from anyone under 18.

Under Article 28 of PIPL the personal information of anyone under 14 is sensitive personal information, carrying a separate consent requirement and a far lower cross-border threshold. We hold none of it. If we discover we have collected data from a child, we delete it.

Complaints

If you think we have handled your data badly, tell the Data Protection Officer first — section 12(b) of the PDPA requires us to have a process for receiving and answering complaints, and this is that process. If our answer does not satisfy you, you can apply to Singapore's Personal Data Protection Commission.

In mainland China the route is a real one and worth naming precisely, because the company answerable for your data is established there. Article 65 of the Personal Information Protection Law gives any organisation or individual the right to complain about or report unlawful handling to the departments performing personal information protection duties, and requires those departments to deal with it promptly and to tell you the outcome. The department in question is the cyberspace administration — the CAC's own standard contract for cross-border transfers defines the regulator as the cyberspace administration department at or above provincial level, which for us means Guangdong. We are not publishing a phone number for it: Article 65 puts the duty to publish contact details on the department, not on us, and a number we transcribed and never tested is worth less than telling you which body to look for.

Separately, and this one is about us rather than about a regulator: Article 50 of PIPL requires a convenient mechanism for exercising your rights and requires us to give reasons whenever we refuse a request, and if we refuse you may bring proceedings in a people's court. China's Network Data Security Management Regulations, in force since 1 January 2025, also require anyone providing a service to the public to publish a working channel for data-security complaints and reports and to deal with them promptly. The address at the foot of this page is that channel. It is not a different one.

In the EU you may complain to the supervisory authority where you live, where you work, or where the problem happened. We have no establishment in the Union, so there is no single lead authority to name, and we are not going to name one to look more settled than we are.

Changes, and which language governs

When this page changes, the date changes with it, and the new version applies from the date shown. We will not slip a new purpose past you by editing this page quietly. If we ever want to use enquiry data for something not described here, you get told before it happens rather than after — that is what section 20(1)(b) of the PDPA requires and what Article 13(3) of the GDPR asks of a controller, and where consent is the basis we ask again under Article 14 of PIPL. Your stored consent wording protects you here too: an edit to this page cannot change the sentence sitting in your row.

The English and Chinese versions of this page are both authoritative; neither is a convenience translation of the other. Where the two could be read differently, the reading more protective of you is the one that governs. That rule belongs to this page and was chosen for this page: a privacy policy should resolve in favour of the individual. It is the opposite of the usual clause, which quietly demotes one language to a courtesy.

This page describes what we do and what the law requires of us. It is not legal advice, and it is not a substitute for your own.

The person to write to

Section 11(5) of Singapore's PDPA requires us to make our Data Protection Officer's business contact information publicly available, and every request, withdrawal, objection and complaint described on this page arrives here.