This document is a draft and is not in force.
What it says about the software is written from the software and is accurate. What it
cannot say is the contracting legal entity, the governing jurisdiction, an address for legal notices, an address for privacy requests and an effective date — none of which is
knowable from the code. Until those are set in marketing/src/site.ts, no
agreement is formed by this page and nothing on it should be relied on. This notice
removes itself once they are.
Privacy
What we hold, and what we cannot reach
This describes Superior CRM as it is built. Where the software has a limit — a place an erasure does not reach, a check that records "we could not look" — this says so, because a policy that lists only what works is not a description of the system.
Two different roles, and the difference matters
Superior CRM is sold to businesses — ISOs, agent offices, processors and bank merchant-services teams. That means two distinct relationships, and almost everything below depends on which one is in play.
For our own customers — the businesses that buy Superior CRM, and the named people who log in — Superior Payments decides what is collected and why. We are the controller of that account data.
For everything a customer puts into the system — their leads, their merchants, the principals on an application, the people who open their support tickets — the customer decides. They are the controller; we process on their instructions and hold it on their behalf. We do not sell it, mine it, use it to train anything, or move it between customers.
The second relationship is enforced in the data layer rather than by policy. Queries are scoped to one organisation by a database client extension, so a feature that forgets to filter cannot leak across customers — the filter is not the feature's to forget. If you are a merchant, a lead, or an applicant, the business you dealt with holds your record and answers requests about it; we act for them.
This website sets no cookies
Not "essential cookies only". None. These marketing pages are rendered to static HTML at build time, ship no client-side JavaScript, and call no API — the only link to the product is an ordinary link. There is no analytics, no tag manager, no pixel, no embedded video, no font fetched from somebody else's server, and nothing that could set a cookie if it wanted to.
The server that hosts these pages writes ordinary web access logs, which include IP addresses, and it sends a strict-transport-security header so a browser refuses plain HTTP to this domain for a year.
The application uses exactly two cookies
| Cookie | What it does |
|---|---|
| crm_session | The signed session token. Marked http-only, so page scripts cannot read it and a cross-site script cannot steal it. Expires after twelve hours by default. |
| crm_csrf | A value the application must echo back in a header on every write. Readable by the page on purpose — that is the mechanism. A forged request from another site can send your cookie but cannot read it to echo it, so the write is refused. |
Both are strictly necessary to sign in and stay signed in. There are no advertising, analytics or profiling cookies in the application either. Cookies of this kind stop a session token being stolen; they do not stop it being misused by somebody already at your keyboard, and we do not claim otherwise.
What the application holds
Account data, about the people who log in: name, email address, phone number, role, the organisation they belong to, a password stored as an argon2id hash rather than as a password, and — where enabled — a two-factor secret and single-use backup codes. Sessions can be revoked individually.
Customer records, which our customers enter or import: leads and their contact details, merchants and their business details, applications and the principals named on them, bank account details, uploaded documents such as identity documents and bank statements, call logs and recordings where the customer has enabled calling, text-message consent records, support tickets and their replies, and the residual and payout figures that follow from all of it.
An audit trail. Every mutating request is logged with the acting user, and every lifecycle event is written to an append-only ledger which is sealed hourly into chained checksums. This exists so that a dispute about what happened to a merchant file has an answer, and so that an erasure can be proved to have occurred.
Sensitive identifiers are encrypted at rest under a rotating key — ten columns across the schema, including tax identification numbers, social security numbers and bank account numbers. Three of those carry a blind index, which lets the system recognise a number it has seen before without being able to read it back. For a social security number only the last four digits are readable, and only those are ever returned.
What it never holds
Card numbers. There is no column for a primary account number, security code, magnetic-stripe track data or PIN block anywhere in the schema. A stored payment instrument is a token issued by a payment provider, plus a brand, the last four digits and an expiry date.
That is a claim about the database rather than a promise about conduct, which is what makes it checkable — and it is checked. Incoming webhook payloads from processors are redacted before they are written: by field name, and also by value, replacing any card-shaped digit run anywhere in the body including inside free text, because the field names belong to the processor and nobody here can enumerate them. An end-to-end test posts a real test card under an unexpected key and buried in a sentence, and asserts neither survives.
Superior CRM also does not move money. It records, calculates and reconciles; it does not hold funds, initiate transfers or debit anybody.
Who else processes it
| Who | For what |
|---|---|
| Microsoft Azure | Hosting, the database, and the storage account holding uploaded documents. |
| SendGrid | Outbound email, when a deployment has it configured. Email is queued and delivered with retries rather than sent inline, so a message is not lost when a send fails. |
| Twilio | Text messaging and calling, for customers who enable them. These run on the customer's own Twilio account and credentials, so the relationship is theirs rather than ours. |
| Card processors | Whichever acquirers a customer boards merchants to, using credentials they supply. What is sent is the merchant application the customer chose to submit. |
| US Treasury (OFAC) | The sanctions list is downloaded and matched locally. No name is sent to Treasury, so screening discloses nothing to anybody. |
Sanctions screening, and what it is not
Merchants and the principals on an application are screened against the OFAC Specially Designated Nationals list. A possible match holds the file for a person to review — it does not reject anybody automatically, because a name match is a question and not a verdict.
When a check could not run — screening switched off, a list that failed to download, a blank name — the result recorded is unknown, with the reason, and never a pass. That distinction is load-bearing: a check that quietly returned "clear" when nobody looked would leave a clean audit trail saying somebody had, which is worse than no screening at all.
This is one list. It is not identity verification, business verification, a MATCH or TMF enquiry, or a credit check — none of which this product performs.
Access, correction and erasure
A request for a copy of what is held, or for it to be erased, goes to the business you dealt with. Their administrator runs it against their own organisation; both are built into the product and are keyed on an email address or phone number you give, never on an internal identifier that might point at somebody else.
There is deliberately no self-service version. Automating it would mean verifying the identity of somebody with no account, and getting that wrong hands one person another person's file. That is a larger risk than the one it would solve.
An erasure empties rather than deletes. Rows remain and their identifying columns are cleared, because deleting outright breaks the things that must survive — a residual attached to a settled deal, a transaction that has already moved, an audit entry that refers to the row. What has to go is the ability to identify a person, and that is what goes. Free text a person wrote about themselves — an enquiry, a message — is cleared alongside the identifiers.
What survives an erasure, and on what basis
Retention is not a loophole, so each of these names the obligation it rests on. "We would rather keep it" is not one of them, and the export report tells the person what was kept rather than leaving them to assume everything went.
| Kept | Why |
|---|---|
| Signed agreements | The signature record — timestamp, IP, consent wording, document hash — is what makes the signature enforceable. Erasing the signer destroys the evidence that the signature belongs to anybody. |
| Text-message consent | Kept against a hash. The sender carries the burden of proving a text was permitted — and erasing an opt-out would allow the number to be texted again, which harms the person the erasure was meant to protect. |
| Last four digits and blind indexes | Not readable identifiers. They are what lets a previously declined principal be recognised on a new application. The full number is destroyed. |
| The audit log | It contains the record of the erasure itself. Erasing it removes the proof that the erasure happened. |
| Identity documents | Retained under anti-money-laundering customer-identification obligations, five years past account closure. The person is told this in the response rather than left to assume the file went. |
| Settled money | Transactions, settlements, residuals, payouts and tax forms already reported. These reference a merchant rather than naming an individual, so clearing the contact fields removes the person from them. |
What this does not do
Every item here is a known limit rather than a discovered one. They are listed because a privacy policy that mentions only what works misleads by omission, and because somebody deciding whether this product is adequate for them needs the gaps more than the strengths.
- Erasure does not reach imported source data. Records migrated from another system keep the original export line verbatim, and an address buried in it cannot be found by a search that matches whole fields. This is recorded as an open gap rather than quietly excluded.
- Deleted documents persist briefly. The storage account keeps soft-deleted files for seven days, so "erased" is not immediate. A request that must complete sooner needs a manual hard delete.
- An export does not search free text by content. Somebody named inside another person's ticket note is not found by searching for their email address. The response says so rather than implying the search was exhaustive.
- An export covers one business. The same person may be a lead at two companies using this product. Each answers its own request; neither can see into the other.
- Nothing ages out on its own. There is no scheduled retention sweep. Erasure is requested, not automatic — and audit records are currently kept indefinitely, because no retention window has been chosen and shipping a number nobody chose is how an audit trail gets pruned by accident.
Getting in touch
No address for privacy requests has been set yet, so this page does not print one. An address that is not monitored is worse than none: the sender believes they have made contact and a statutory clock starts running against somebody who never knew.
If your record is held by a business that uses Superior CRM, that business answers your request. We will pass on anything that reaches us by mistake, but we cannot act on their data without their instruction — which is the same boundary that keeps their records away from every other customer.