DATA PATH / 01
Minimal data for a narrow task.
Who controls your data. The data controller is 济南深与国际贸易有限公司, a company registered in Jinan, Shandong, China on 18 August 2026 under Unified Social Credit Code 91370105MAKM7P5L3P, at 山东省济南市天桥区泺口街道济泺路71号华宇云商创新园区25层2518室. For any request about your data, or to reach a person, email hello@currawongweb.com. The full registration record is on the site operator page.
For buyers in the EU/UK: no EU adequacy decision covers China, and we have not yet put standard contractual clauses in place or appointed an EU representative. The mitigation today is data minimisation — submit only what the check needs; email is optional — and deletion on request at any time.
The basis we rely on for the transfer itself is Article 49(1)(b): the transfer is necessary to perform the contract you asked us to perform. That derogation only holds while such transfers stay occasional, which is also why no Article 27 representative is appointed today. When orders from the EU stop being occasional, the derogation stops covering them and a representative and standard contractual clauses become necessary. If your compliance process needs a signed data-processing agreement, ask by email: we will send you ours, or sign yours where it does not contradict what this page says.
Please do not submit passwords, bank credentials, government IDs, private communications or unrelated personal information.
Browser-only tools
The acquisition brief stays in your browser until you choose to send an email. Choosing the email button opens a draft in your email application; you review and send it yourself.
Factory-screen paste mode reads the supplier name and business-scope wording in your browser. It does not send those fields to Currawong or an official registry.
The free checker does keep anonymous daily counters. There are four groups of them.
- That the tool was loaded, that the paste reading was run, that a live lookup was started and whether it returned a record.
- When it did not, which of six fixed failure categories applied (no record, unavailable, blocked, error, network, or offline before it was sent). Also whether what you typed took the shape of an 18-character code, a Chinese name or a Latin-script name, three fixed shape counters that never carry the text itself.
- Once a lookup has returned a record or reported none, which one of five fixed next steps you took first (carrying the record on to the report builder, opening another free tool, opening a guide page, running another lookup, or leaving without any of these). Recorded once per lookup, and never with the page address or the link text.
- Only if you choose to answer the optional sourcing question, a product area and an order-value range picked from fixed lists.
They are stored as one count per day per item. There is no timestamp for an individual use, no IP address, not even a hashed one, no free-text field, and no link to your lookup, your order or you. Because of that structure the counts cannot be traced back to a visit, and cannot be used to contact you. The company name you type into the live lookup is sent to our server to run that lookup, and is not written into these counters. The report builder keeps counters of the same kind: that someone began selecting checks, that they moved on to the order review page, and that an order was submitted. Those three carry no supplier name, no email address, no amount and no record of which checks were chosen.
The report menu page has six separate daily counters. They cover a price label coming into view and links to the specimen, sources section and report terms being opened. The other two record the Advanced menu opening and a valid draft being saved before order review. Each counts at most once per page load; reloading can count again. They carry no link address, company name, selected checks, amount or identifier. A link click does not show that you read the page, and a review draft is not a payment. These totals cannot connect your actions into an individual journey.
One counter of the same kind covers arrivals. If you reach this site by following a link we published elsewhere, and that link carries a campaign parameter, we add one count against the channel name. The name is picked from a fixed list such as LinkedIn or Quora. Anything unrecognised is counted only as other. It is recorded once for the visit, not once per page you then read. The raw parameter text is not stored, no page you read is attached to it, and there is again no IP address and no timestamp for an individual arrival. Arriving without such a link produces no count at all: typing the address, following an ordinary link or coming from a search result sends nothing. We count arrivals this way because referrer information is stripped by several of the places we post. Without the count we cannot tell whether anything we publish reaches anyone.
Counters of the same shape sit elsewhere on the site, and none of them carries anything you typed. The code checker keeps nine. Three cover the check itself: that the page ran, that a code was checked, and whether it passed. One records whether you typed the code yourself rather than opening a link that already had one in it. Two cover sharing: that you copied the result, and that you arrived through such a link. Two record which of the two links out of the checker you followed. One is for people who do not have a code yet. The other carries a checked code on to the free registry lookup. Without them we cannot tell someone who left from someone who moved on to the right tool. One records that you scrolled as far as the section on what a passing code does not prove. The code itself never leaves your browser: the check is arithmetic done on your own machine, and only the outcome is counted, not the value. The language switcher keeps one: that someone used it. It does not record which language was chosen. The verification request form keeps two: that at least one check was ticked, and that the submit button was pressed. Each is recorded once. Neither carries a supplier name, an email address, or any record of which checks were ticked. The four-party payment check keeps three: that a comparison was run, whether its outcome was a hold, and that the result text was copied. The copied text itself carries only counts and the tool address. It never carries the names you typed. Finally, one counter records that a price block scrolled into view, so we can tell "read the price and left" apart from "never reached it". It does not record which page, or how long you stayed. All of them are daily totals with no IP address and no timestamp for an individual event, exactly like the counters above.
Every comparison or reading tool on this site, the paste reader, the code checker, the certificate matching worksheet and anything like them — follows the same rule: what you paste or type stays in your browser unless the control is explicitly labelled as a live lookup or a submission.
Verification requests
When you press the submit button on the company-check form, the application sends a fixed set of fields to the Currawong verification service. They are the supplier legal name, optional Unified Social Credit Code and optional supplier website. The rest is product, selected public-record checks and, only if you choose to fill it in, an email address.
That email address is a delivery channel, not an account. It is used to send you a receipt, to tell you when the check is finished, and to reach you if you lose the private link. Submitting it does not create an account, does not subscribe you to anything and is not used for marketing. It is stored on that one request record. So it is tied to that request and to no wider profile, and the public status page never returns it; only the China-side desk sees it. Leave the field empty and the request stays anonymous, with the private link as the only way back to it. A paid order carries the same optional address on the same terms.
The service stores the request and its later status or result so I can process it and your private link can retrieve it. A salted, short-window hash derived from the request source is used to enforce submission limits. The application does not write the raw source address into its verification tables.
Sourcing briefs (the buying desk). The structured brief at /sourcing/request/ sends exactly the fields shown on that form to Currawong for manual review. Those are company, contact, an optional WhatsApp or LinkedIn handle, destination country and city or postcode, product details and your declarations. It is stored under a random brief reference and is not shared with any lead, marketing or third-party system. The step deliberately collects no street address and no payment information. A brief containing a card-like number is rejected rather than stored. Briefs that do not proceed to a quote are deleted or anonymised as part of routine review. The verification workflow and the buying desk keep separate records. Neither populates the other.
Private result links
Your access secret stays after the # character in the private result URL. Browsers do not send that fragment as part of the page request. The application sends the secret only in a status API request after the page loads, and the database stores a one-way hash rather than the raw secret.
Keep it private. If you lose it, Currawong cannot reconstruct the secret from the stored hash.
Optional live company lookup
Paste mode remains local. If the separately labelled live lookup is configured and you choose to use it, the company keyword is sent to the same-origin Currawong API. That API may query the configured commercial company-data provider. If no provider account is configured, the lookup fails visibly. It does not fabricate or silently substitute a result.
Retention, access and deletion requests
A paid report body is deleted 30 days after delivery. A scheduled sweep removes the stored object first and then clears the pointer to it, so the report stops being retrievable at that point. The order metadata (what was ordered, when it was paid, when it was delivered) is kept after that. The report text is not.
Two shorter windows sit inside that period. A private view session lasts 30 minutes and can be reopened with your link, and the link itself works for 7 days after delivery. After that a person reopens it on request. The retention period can never be configured below 8 days, so the deletion job cannot remove a report you are still entitled to read. An invalid setting falls back to the 30-day default rather than deleting early.
An email address you chose to supply, and likewise an optional supplier contact handle (a WhatsApp or WeChat ID), is not on that 30-day timer. Either sits on the request or order record itself, and no scheduled job clears it. It is kept until you ask us to remove it. The handle refers to your supplier, not to you. It cannot be searched against any registry, is used only for the researcher’s cross-check, and the public status page never returns it. Ask and we clear the address while leaving the request readable through your private link, or delete the record outright if you would rather have neither. We would rather say that plainly than let you assume a sweep exists that does not. Two caps now sit over that. A contact address or handle is deleted 24 months after your last order, or sooner if you ask. Nothing about you needs to sit here longer than that. The accounting record of a paid order is different, and shorter is not an option we have. Under China’s Measures for the Administration of Accounting Archives (Ministry of Finance and National Archives Administration Order No. 79, in force 1 January 2016) the fixed retention classes are 10 and 30 years, counted from the first day after the accounting year ends, and the schedule sets floors, never ceilings. So what an order leaves behind after 24 months is the transaction itself, the amount, the date and the payment reference, and not a way to contact you.
Requests submitted without an order follow the same principle in the other direction: send only the minimum supplier information the check needs. Do not submit passwords, bank credentials, government IDs or unrelated personal information at any point.
To ask what application data is associated with a request, request correction or deletion where applicable, or report a private-link exposure, email hello@currawongweb.com with the request ID. Do not include the private result secret in ordinary email unless specifically required to verify access.
Contacting the desk on WhatsApp
The WhatsApp link on this site is a redirect. It sends your browser to WhatsApp and stores nothing on our side: no cookie, no identifier, no record that you clicked it.
If you then send a message, that conversation is carried by WhatsApp and processed by Meta Platforms under their terms and privacy policy, not ours. We see the message together with whatever display name and phone number WhatsApp shows us. We do not import those contacts anywhere, and we do not add you to any list.
Email stays available for anything you would rather not route through a third-party messenger. On either channel, do not send passwords, payment credentials or personal data unrelated to the check.
Payment and email providers
When you pay, the payment itself happens on the processor's side. That is PayPal for PayPal and the on-page card fields (the route that is live today), Shopify for Shopify secure checkout, or Stripe when card checkout is enabled. Your card number, account login and bank details go to the processor, never to Currawong. Every processor receives the order ID, amount and currency needed to reconcile the payment. PayPal and Stripe may also receive the supplier name in the payment description and use the billing descriptor CURRAWONGWEB. Shopify receives the report product or generic report line, the internal order ID, the applicable terms version and, only if you supplied one, your email address. The supplier name and private report subject details remain in Currawong's order record. We do not send any processor your browsing activity on this site. Each processor handles the data it receives under its own privacy policy.
If you leave an email on an order, the order confirmation, payment receipt and report-ready notices are delivered through Resend, an email delivery service. Each such email carries your address, the order ID, the supplier name you entered, the amount and your private order link. Resend processes it as our delivery provider. We do not use it to build any marketing list.
Site measurement
This site loads a Google Analytics 4 tag operating in Consent Mode v2 with analytics_storage denied. That mode instructs the tag to set no cookie, generate no client identifier and assign no session identifier. Google receives a cookieless ping for each page view: the page URL, page title, referrer, screen resolution, browser language and, when a link you followed to reach this site carried campaign parameters (utm_source, utm_medium, utm_campaign), the values of those parameters. Those pings cannot be joined across visits by the tag or by Google Analytics because there is no stored identifier linking one visit to another.
The purpose is channel attribution: knowing whether a link we published on LinkedIn, Quora or another platform was followed at all, and seeing aggregate page-view counts, without identifying or tracking individual visitors. Google processes these pings under its own terms; we do not receive user-level data from them and cannot reconstruct a browsing path or identity from the aggregate reports Google Analytics makes available to us.
This tag runs alongside the existing Cloudflare Web Analytics beacon described in section 01. The Cloudflare beacon is injected by Cloudflare's edge network and operates independently of Google Analytics. Between the two, neither sets a cookie and neither creates a user identifier.