Skip to content
SCMTR
Check JSON

Legal

Privacy Policy

Last updated: 7 October 2026. This policy explains what data the SCMTR platform ("we", "us") collects, why, who it is shared with, and the rights you have over it — written to be read, not skimmed past.

Who we are

The SCMTR platform at scmtr.io is operated by TAGQA PTY LTD (ABN 45 634 337 778), Melbourne, VIC, Australia. For anything in this policy, contact support@scmtr.io.

What we collect

  • Account data. Your name and email address, received from the sign-in provider you choose (Google, Microsoft, or an email sign-in link), and the time you last signed in and the day you were last active — so that an administrator can tell whether an account is in use. We never see or store passwords for these providers.
  • Organization and declaration data. The customs filings you prepare: organization profile, vessel and voyage details, and consignment information — which includes personal data about third parties you enter, such as consignor and consignee names, addresses, and identifiers (for example PAN). You are responsible for having the right to submit that data; we process it solely to prepare and file your declarations.
  • ICEGATE credentials. Filing credentials you save are held in a dedicated secret store, encrypted, and referenced only by an opaque pointer — never stored in the application database and never shown back in full. An organisation's own ICEGATE portal login, saved separately to run certain look-ups under that organisation's own account, is encrypted and held in our database rather than the secret store; it is never shown back in full and is never used for another organisation's look-ups.
  • Audit records. Administrative and filing actions are logged (who did what, and when) — including the real operator during any support impersonation session — because a customs filing tool must be able to answer that question. The log is kept for twelve months, then deleted — except its record of your filings (who sent each one, what customs answered, every read of a kept file and every support session), which is kept as long as the filings are.
  • Chatbot questions. Questions you type into the SCMTR assistant are processed to generate an answer. If you are signed in, the question and its answer are kept for 90 days, with your account and organisation, so we can see where the answers fall short and improve them. A question asked on the public site without signing in is kept for 90 days too, with its answer and the page it was asked from, and with nothing that says who asked — no name, no e-mail address, no IP address and no cookie. Because nothing ties such a question to you, we cannot find it from your name or address; to have one deleted sooner, send us its wording. (The request logs described under technical data below are separate, and are kept whether you sign in or not.) Questions are answered by Google Vertex AI (see below). Please do not paste consignment details — bill numbers, party names, a whole filing — into the assistant; use the file check instead.
  • Technical data. A session cookie (httpOnly, needed to keep you signed in). Your IP address, used to limit abuse on the parts of the site that need no account: the assistant, the feedback form, the public roadmap (votes and its search for similar suggestions), the file check at /check and holding a checked file through sign-in, Track when you are not signed in, the “Was this helpful?” question on a shared answer, the preview images drawn for a shared link, and requests for a sign-in link — and, as a one-way code only, for counting distinct visitors a day (page counts, below). For that, the address is the key of a short-lived counter. Most of these counters expire within ten minutes, but the daily allowances for the assistant and for the roadmap's similar-suggestions search are kept against your address — or, when you are signed in, your account — for up to about a day (26 hours), and a shared answer's vote is kept against it for a day so that it counts once. If you vote on the public roadmap without signing in, we store a one-way fingerprint derived from your IP address alongside the vote — enough to stop the same visitor voting twice on one item, and not reversible to recover the address or identify you. None of these counters puts the address itself in our database. When you sign in, we do record the browser or app and the IP address that sign-in came from, so that Settings → Sign-ins can show you where you are signed in and we can e-mail you when your account is signed in to from a device it has not used before. To tell a browser you have used before from a new one, it is given a device cookie (httpOnly, a random value, kept by your browser for up to 400 days and not cleared when you sign out); we store only a one-way code made from it. Separately, our hosting provider's request logs record the IP address every request to the site came from, and those logs are kept for 30 days. We run no third-party analytics or advertising trackers.
  • Usage events. When you use a feature — opening a file in the inspector, saving a manifest, submitting a filing, checking a bill on Track — we record that it happened, whether it succeeded, and your account and organisation identifiers. They go to our own operational logs, which are deleted after 30 days, and are kept in our own database for 30 days as well — the same window, so they go when the log lines they mirror do. They exist so we can tell which parts of the product people actually use and where they get stuck; they are never sold, shared, or used to advertise to you. For a new account, we also record which of our own pages the sign-up started from — chosen from a fixed list, such as the home page or the file check, and never the address you arrived from. A usage event holds identifiers and fixed categories only: it records that you opened a file, never anything from inside it — no bill of lading number, no party name, no filename, no consignment data of any kind.
  • Page counts and daily totals. When a page of this site is shown, your browser tells us its address (without the part after a question mark), whether it was the public site or the signed-in app, the site you came from (its address only, never the page) and a link's campaign tag if it carries one. We keep only the page's shape — its address with any bill, job or link identifier taken out — the kind of site you came from (a search engine, WhatsApp, typed in), whether you are on a phone, a tablet or a computer, and the hour of the day. It sets no cookie. To count how many different visitors came on a day without following anyone, your IP address and browser description are combined with a random key made afresh each day and deleted within about a day and a half, and only a one-way code made from them is added to a counter that keeps no entry of its own: nothing about you is stored, and a visitor on one day cannot be connected to a visitor on the next. A browser that sends Global Privacy Control or Do Not Track sends nothing at all. We also count, a day at a time, the requests the platform makes to ICEGATE and to our other service providers, the files checked and what the checks found — by field of the form or by customs' error code, never a value from the file — the one-press fixes used, and, on the CSN cut-off board, each search by whether it found a call with its cut-off, one without, or nothing (never the words searched) and each time a cut-off is shared, added to a calendar or printed. What we keep of all this, and of the usage events above before they are deleted, is daily totals only: a number per day per category, naming no person, organisation, file or bill. Those totals are kept indefinitely, so one year can be compared with the next.

How we use it

To provide the service: preparing, validating, and — on your explicit instruction — submitting declarations to ICEGATE and retrieving customs decisions; to keep your account and organization data isolated and secure; to answer support requests; to link a filing with its replies and amendments over time; to improve how SCMTR reads and checks files, using the files people upload (see Files you upload, below); to meet legal obligations; and to protect the service against abuse. We do not sell personal data, and we do not use your declaration data or uploaded files to train AI models or for advertising.

Who it is shared with

  • Indian Customs (ICEGATE/CBIC) — your declarations are transmitted there when you submit them; that is the product.
  • Infrastructure processors — each processes data only on our instructions, and they are not all in India:
    • Google Cloud Platform, Mumbai region. The application, its database — your account, your organisation, the filings you keep, the details of files you upload, stored assistant questions and usage events — and that database's backups; a private storage bucket holding the uploaded files themselves, compressed; and our cache, Redis. Redis is not a separate company: it runs on a Google Compute Engine virtual machine we operate ourselves, in the same Mumbai region. It holds short-lived data only: sign-in requests while they wait to be approved, access tokens, rate-limit and e-mail allowance counters, a note of which account holders' summary or tip e-mails recently failed to send (so a bad address is not retried every minute; kept up to 30 days, by account identifier), a note that an address with no account has already been sent our sign-up reply to a file it e-mailed us (up to 7 days, so it gets one a week at most), and, briefly, whole files — up to 30 minutes for a file you carry from /check into sign-in, and up to 24 hours for a file behind the link in an e-mail check report.
    • Google Vertex AI. Questions you type into the assistant, and text typed into the roadmap's suggestion box to find similar suggestions, are sent to Google's Mumbai region (asia-south1) to find matching material. The assistant's answer is then written by a model Google serves only from its global endpoint, so the question and the material found for it may be processed in any of Google's regions, and may leave India to be answered. So are suggestions you send us through the feedback form, when our staff review them: they are matched in Mumbai, and grouped and drafted into wording for an entry on the public roadmap through the global endpoint, which a member of staff then edits before anything is published. Bills you e-mail to our bills address, and the text of that e-mail, are read by Google's Gemini models through the same global endpoint, so they too may be processed in any of Google's regions (see Sending bills by e-mail, below).
    • Anthropic, in the United States. When you e-mail us bills, each bill is read a second time by Anthropic's Claude, through Anthropic's own service, to check the values that matter most — bill and container numbers, seals, counts, weights and party codes — against the first reading. Only the bill itself is sent. Under Anthropic's commercial terms it does not use what we send to train its models.
    • Google Workspace. Our e-mail, which Google does not keep in any particular country. That covers mail we send you (sign-in links, invitations, summaries) and mail you send us — including a file you e-mail to our checking address, which arrives in a Workspace mailbox before it is checked (see Checking a file by e-mail, below).
    • ZeptoMail (Zoho), through its Australian data centre. A second route for the same outgoing e-mail, used only once our daily Google sending allowance runs low.
    • Google Cloud Logging. Request logs and our operational logs, kept for 30 days. We have not configured these logs to stay in a particular region.
  • YouTube (Google), on the film pages only. A page under /films plays one of our walkthrough films in YouTube's privacy-enhanced player, loaded from youtube-nocookie.com. Opening such a page connects your browser to Google, which sees your IP address and browser as any site you visit does; YouTube says that in this mode it stores nothing about you until you play the film, and once you do, YouTube's own privacy policy applies. We send YouTube nothing of ours, and no other page of this site loads anything from YouTube — a film link anywhere else opens the film's page here.
  • Authorities — if legally required, under valid legal process.

How it is protected

Encryption in transit (TLS everywhere) and at rest; database-level row isolation so one organization can never read another's data, enforced in the database itself rather than only in application code; filing credentials in an encrypted secret store; and revocable, database-backed sessions so access ends immediately when a role is removed.

Files you upload

We keep every file uploaded to SCMTR. That covers declarations, signed declarations, acknowledgements, vessel manifests and customs' replies to them. It applies on whichever screen you upload them: SCMTR JSON upload, your CSN filing page, a filing's page, Record a filing made elsewhere, the Shipping line filing page, the mobile app. It also covers a signed file you send to customs from here. A vessel manifest you open is uploaded and kept too, although it is still read and edited in your browser. The file is kept exactly as it arrived, compressed, in a private storage bucket in Mumbai, with the details it states about itself (sender, job number, port, vessel call, bills of lading) in our database.

We keep a file for two years after we last receive it, or for as long as a filing in SCMTR still relies on it, and then delete it automatically. We use kept files for three things: to help you when you write to us about a filing; to link a filing with its replies and amendments over time; and to improve how SCMTR reads and checks files — for example, a real refusal becomes a test that future checks must pass. We do not sell them, advertise with them, or use them to train AI models.

A platform super administrator can open any kept file, and every time one is opened we record who opened it and which file — a record you can ask to see. You can ask us to delete a file at any time, and we will. These files often are not only about you — a filing you were sent to check names someone else's consignor, consignee and cargo. Upload only files you have the right to share with us for these purposes.

A file uploaded before 17 September 2026 to Check an ICEGATE file (now SCMTR JSON upload) was kept for seven days under the policy then in force, and is deleted when those seven days end. Nothing uploaded before that date is kept for longer.

Checking a file without signing in

The free check at /check needs no account. A file you drop on it is kept, as above, for two years. Because you are not signed in, it is kept under no account. Beside it we store a one-way code made from your IP address and the date, which lets us see that several files came from one visitor on one day; the code cannot be turned back into the address and changes every day. If you choose to continue to sign-in to see every problem, we also hold the file for 30 minutes so that it opens for you once you have signed in.

Checking a file by e-mail

A file you e-mail to our checking address from your account is kept, as above, for two years, whether or not it could be checked. The link in our reply that opens it in SCMTR works once, for 24 hours.

When an e-mail to the checking address has no JSON file attached, we read its text to decide how to answer it, and we do not store that text anywhere outside the mailbox itself. We look for three things in it: one of ICEGATE's own refusals, so our reply can explain what it means — that reply quotes the one line it recognised, answers under the same subject, and, where the message reached your own checking address from somewhere else, names the sender's address as unverified; one of our own replies forwarded back, which we do not answer; and, in mail sent to your own checking address from Settings, Gmail's confirmation of a forwarding rule, which we quote whole so that you can finish setting up the rule. Every such reply goes to the address on your account and to nobody else. When an e-mail does carry a JSON file, we check the file and do not use the e-mail's text.

The checking address is a Google Workspace mailbox, so the e-mail you sent — with its attachments — is also held by Google Workspace, which does not keep mail in a particular country. It stays there so we can deal with abuse and answer you if you write to support about it. It is deleted by a retention setting on that mailbox, which removes mail older than 30 days; SCMTR itself only marks each message as read once it has been answered.

Sending bills by e-mail

Where your organisation uses it, you can e-mail a master bill of lading and its house bills to our bills address, and we draft a checklist for a CSN from them. To do that we send each bill, and the text of your e-mail, to two AI models: Google's Gemini, through Google Vertex AI's global endpoint, reads the whole bill; Anthropic's Claude, in the United States, reads it again to check its critical values. They are sent only to be read. We keep the result, not the models, and neither may use what we send to train its models.

The bills you attach are kept as every file you upload is, for two years. The checklist — what was read off the bills, your e-mail's own text, any questions we asked and your answers — is kept for two years, as the files are, then deleted. The link we send you to answer a question works for 14 days, and we keep only a one-way code made from it. The bills address is a Google Workspace mailbox, so your e-mail and its attachments are also held by Google Workspace, which does not keep mail in a particular country. Only mail from the address of an SCMTR account allowed to send bills, in an organisation using the feature, is read by a model; anyone else gets at most a short note, once a week, saying the feature is not on for them.

To make the drafts better, SCMTR's own staff compare each checklist's draft with the CSN customs accepted for the same bills, value by value — what the draft got right, what it left blank and what was filed instead. Only SCMTR's staff see the comparison; it is kept with its checklist, for two years, and deleted with it.

Filings SCMTR.io prepares for you

Where we agree to prepare a filing for your organisation — an amendment to a vessel manifest, say — our staff build it from what you and customs' public record give us, and hold it in your account for you to sign with your own DSC and send from SCMTR.io — or, before you have an account, behind a private link that adds it to the account of whoever first opens it and signs in. The file is stored encrypted; you see a summary of what it sends, and SCMTR.io keeps the signed copy that went to ICEGATE. Both are kept for two years from the filing's last change, then deleted, and sooner if your organisation is deleted. Customs' answer to it comes to your ICEGATE ID as any filing's does.

The CSN cut-off board, for shipping lines

Shipping lines and their agents publish each vessel call's CSN cut-off on our cut-off board by e-mailing their customer advisory to our lines address, or from a desk link we e-mail to their work address. We publish only for a line whose mail domain our staff have verified, and only mail that domain has authenticated. To read an advisory we send its attachments and the e-mail's text to Google's Gemini, through Google Vertex AI's global endpoint; it is sent only to be read, and Google may not use it to train its models. To compare a call with customs' record we ask ICEGATE's public vessel enquiry about the ship.

What the line publishes — the vessel, the port, the dates and the call's identifiers, a short note, and the advisory file itself — is public on the board, with the line's name and verified domain. The sender's own name and address are never shown; we keep the address, the e-mail's text and the files for one year, then delete them. The published notices and their history are kept, because their links are in other people's messages; a line can withdraw any of them at any time. A desk link works for 30 days; we keep only a one-way code made from the link itself, and the work address it was sent to until a day after it expires. The lines address is a Google Workspace mailbox, so the e-mail is also held by Google Workspace.

Mail sent to the lines address by someone who is not a verified line — a line not yet set up, or a message sent there by mistake — is kept the same one year with its files, except a reply from someone who is not a line (a “Reply all” to a line's advisory), which is neither kept nor answered, for our staff to verify or set aside; it is never published unless a line is verified for it. When you ask for a desk link, the address you typed is held for a day to limit how often links are sent. A page view of a call is counted once a day per visitor: the network part of your IP address is held for a day to do that, and only the count is kept. Some calls on the board are read by us, twice a day, from lists that ports and lines publish (JNPA's and Visakha Container Terminal's berthing reports, Maersk India's lists), and others from customs' public record of vessel calls — the calls of ships that vessel searches have brought us, and of every ship named (by its IMO number or a VCN) in the last 30 days in a file a signed-in person kept with us, a manifest, a vessel call, a call on the board or a bill tracked to its ship, which we ask customs' public enquiry about by ourselves. We ask customs for the ship's number only, never for anything else in the file; those calls name ships and voyages, never a person.

E-mail from us

We send account e-mails: sign-in links you ask for, invitations to join an organisation, the CSN alerts you choose to send, replies to files you e-mail to our checking address, and our staff's reply when you send us feedback. We also send notices about a filing to the person who created it, when something outside SCMTR changes under it: another filer's CSN, or the shipping line's manifest, disagrees with yours for the same bill; or customs' vessel-call list moves — it no longer lists the call your filing names, it now lists a call for a draft saved without one, or the expected arrival has moved. All of these are sent whatever your e-mail settings, and carry no unsubscribe link.

Unless you turn it off, we also send a weekly summary of the files you checked and, now and then, a tip about something you have not tried yet. Both start from 23 September 2026 and only ever count what you do from that day on. Only these two can be switched off, and they can be stopped in one click — from the “Stop these e-mails” link at the foot of each one, or with “Weekly summary and occasional tips” in Settings. We do not e-mail you about changes to this policy; we show you what changed the next time you open SCMTR and ask you to accept it.

How long we keep it

Account and organization data for as long as your account exists. Filed declarations — every version, when each was sent and what customs answered — are retained after account closure only as long as customs-law record-keeping obligations require, then deleted. The activity log (who did what, and when) is kept for twelve months, then deleted, except its record of filings, kept as long as the filings are. Files you upload, from any screen, signed in or not and by e-mail, two years after we last receive them, or as long as a filing in SCMTR still relies on them (above) — with an e-mail itself deleted from the checking mailbox by its 30-day retention setting, and a file carried into sign-in held a further 30 minutes for that purpose. A checklist built from bills you e-mail — what was read off them, your e-mail's own text, the questions and your answers — is kept for two years, as the files are. Work in progress has its own shorter lives: a draft you never entered anything into is removed after 24 hours, the rolling autosave history of a draft nobody has opened in 30 days is dropped while the draft itself stays, and a saved vessel manifest is kept for 90 days after it was last touched. Chatbot questions and their answers, 90 days, whether you were signed in or not — a question asked without signing in is kept without anything that identifies you. Usage events, 30 days in our logs and 30 days in our database. Request logs, including the IP address each request came from, 30 days. Rate-limit counters keyed on your IP address, from a minute up to about a day (26 hours for the assistant's and the roadmap search's daily allowances); expired session tokens and sign-in links are deleted, not merely refused. The browser and IP address recorded for a sign-in go with that session, when you sign out or it expires; a device you have signed in from is remembered, with the address it was first and last seen from, for a year after it was last used. Alerts raised on your vessel calls, 180 days. A record of a webhook delivery, once it has succeeded or been given up on, 30 days (one still owed is kept until it is). Finished background work, such as a manifest reconciliation once it has run, 30 days. A bill's arrival as the shipping line last gave it, and any arrival date your team typed in, 90 days after anyone in your organisation last looked the bill up or changed it. A share link you send someone outside your organisation — a handshake link, or a case invitation — and its token, up to 90 days after it expires, is withdrawn, or is used up, by which time it no longer opens for anyone. The message a filing agency sends with a request to act for your company, and the reason an engagement ended, are blanked 90 days after the engagement is over; who acted for whom, when and on what terms stays as a record. When you e-mail a CSN that is not a filed one here — a draft, or a file you only checked — the copy of that document carried in the message is kept with the message's own link and dropped 90 days after the link expires; the record that the message was sent, to whom and when, is kept like any other record of a document leaving the platform.

Your rights

Under India's Digital Personal Data Protection Act, 2023, you can request access to, correction of, or erasure of your personal data, and you can withdraw consent for processing that relies on it (which may mean closing your account). Write to support@scmtr.io and we will respond within the statutory timelines. Grievances are handled by our Grievance Officer — the Privacy Team at TAGQA PTY LTD, reachable at support@scmtr.io (mark your message "Grievance"). If you are unsatisfied with our response, you may approach the Data Protection Board of India.

How to delete your data

Email support@scmtr.io from the address you sign in with, asking us to delete your account. Say so plainly — there is no form to fill in. We confirm the request, then remove your account, your profile data, and the link between you and any sign-in provider you used.

Two things survive that deletion, and you should know before you ask. Declarations you filed with customs cannot be unfiled, and we are obliged to retain them — every version, when each was sent and what customs answered — for as long as customs-law record-keeping requires; they are deleted when that period ends. The activity log goes after twelve months, as it does for everyone, apart from its record of those filings, which stays with them. Where your organization has other members, the organization and its filings continue to exist without you. If you are its only member, both go.

We act within the statutory timelines set out under Your rights above, and write back to confirm when it is done.

Children

The service is a business tool for customs filing and is not directed at anyone under 18. We do not knowingly process children's data.

Changes

If this policy or our terms change materially, the next time you sign in or open a signed-in page you will be shown what changed and asked to accept it before you carry on using SCMTR; nothing uploaded by you is kept under the new terms until you have. The “last updated” date at the top of this page is the date its wording last changed, not the date any change takes effect.

Two of the changes made to this policy on 13 September 2026 were withdrawn on 22 September 2026, before they ever took effect: keeping a question asked of the assistant without signing in, and keeping usage events for longer — usage events are deleted from our database after 30 days, as they are from our logs. From 30 September 2026 a question asked without signing in is kept, for 90 days and with nothing that identifies who asked, as set out under Chatbot questions above; one asked before that date was answered and not kept, and the assistant says so beside the box you type in. The third — the weekly summary and the occasional tip, which you can turn off — starts from 23 September 2026 and counts only what you do from that day on. The e-mail we had begun sending every account holder about the 13 September changes was withdrawn with them: a material change now reaches you through the screen described above, the next time you open SCMTR. The change of 17 September 2026 — keeping every uploaded file — applies to your uploads from the moment you accept it, and to uploads made without signing in from that date.

See also the Terms of Service, which govern use of the platform itself.