The platform's privacy posture, in plain language.
What we collect, why we collect it, where it lives, how long we keep it, and how you (and your borrowers) get it back or get rid of it.
Last updated:
What we collect
The personal data RateStack handles falls into three buckets: account data (your operators), borrower data (the loans you import or price), and telemetry (request logs, traces, audit rows).
Account data
- Email, display name, phone (optional), professional title, company, primary state of operations.
- Authentication credentials — bcrypt password hash or OAuth identity from Google / Microsoft / Apple.
- RBAC role assignments and permission grants.
- API keys (SHA-256 hashed; the plaintext is shown once at creation and never persisted).
Borrower data
- Borrower attributes used in pricing — FICO, income (for AMI), DTI, residency status. The platform consumes minimum-necessary fields.
- Loan attributes — amount, type, amortization, term, lock period, occupancy, doc type.
- Property attributes — type, state, county, appraised value.
What we do not collect: Social Security numbers, full credit reports, bank accounts, full appraisal documents, identification documents. The pricing engine does not require them. If a MISMO import contains them, they are stripped before persistence by the PII redactor.
Telemetry
- API request logs (method, path, status, latency, correlationId) — PII-redacted.
- OpenTelemetry traces — exported to your collector if configured; PII-redacted.
- Audit log rows for every state change — actor, action, target, before/after diff (PII-redacted).
Why we collect it
We collect the minimum necessary to operate the service. Specifically:
- Account data — to authenticate operators and authorize their actions.
- Borrower data — to compute pricing, eligibility, and lock state for the lender.
- Telemetry — to operate, debug, and audit the platform.
We do not collect data for advertising, third-party analytics, or model training across customers. The hard rule: if data leaves your tenant, it is because an operator explicitly emitted it (e.g., a webhook delivery to a URL you configured).
PII redaction
Logs, audit rows, and OpenTelemetry spans run through PiiRedactor before persistence. The redactor scrubs:
- Email addresses (case-insensitive RFC 5321 pattern)
- Phone numbers (NANP and international formats)
- SSN-shaped sequences (
NNN-NN-NNNN) - Credit-card-shaped sequences (Luhn-validated)
Redaction is pre-write, not post-process. We do not rely on the downstream log store to redact for us. The redactor is itself audited: changes to the regex set are versioned and require a code review.
Retention
Default retention windows:
| Data class | Default retention | Configurable |
|---|---|---|
| API request logs | 90 days | Business+ tier |
| Ratesheet raw blobs | 90 days post-supersede | Yes |
| Ratesheet rows (versioned) | Indefinite | Custom on Enterprise |
| Audit log | Indefinite | Compliance-driven |
| Webhook deliveries (delivered) | 30 days | Yes |
| Webhook DLQ | 90 days | Yes |
| Event streams (NATS JetStream) | 7-180 days by stream | Per-stream |
Retention is enforced by a daily ShedLock-guarded retention runner that deletes rows older than the configured window. Each deletion writes a summary metric so you can monitor it.
Data subject rights
For your operators (RateStack accounts):
- Access — operators can review their own data via /profile.
- Correction — via /profile or admin API.
- Deletion — admin-initiated; the account is anonymized in audit rows (replaced with a stable opaque id).
- Portability — admin API exports operator data as JSON.
For your borrowers — you are the data controller; we are the processor. Subject access, correction, and deletion requests should be routed through your operations. RateStack supports these actions via the admin API and commits to a 30-day deletion SLA in the DPA.
AI & model training
The mapping resolver in ingestion-service uses an AI client to fall back when stored templates do not match. Important distinctions:
- The AI client is configurable per environment — Anthropic, OpenAI, Gemini, or local Ollama.
- Inputs sent to the AI client are header strings only — no borrower data, no rate values, no investor identifiers beyond what is in the header itself.
- Resolved mappings persist as templates in your tenant only. Templates are not aggregated across customers.
- We do not use customer data to train shared AI models. Period. This is not a roadmap item; it is a contract.
If we ever offer a feature that requires cross-tenant aggregation (e.g., a shared mapping bank), it will be opt-in with explicit consent and a separate addendum. The default is no aggregation.
Frequently asked
Privacy questions, answered.
What's the difference between this page and the Privacy Policy?
This page describes our engineering posture — what the platform does with data. The Privacy Policy at /legal/privacy is the legal document. They are consistent; if you spot a discrepancy, please email security@ratestack.com.
Do you sell data?
No. We do not sell, rent, or license customer data to third parties under any circumstances. This is a hard rule, not a market position.
Do you train AI models on our data?
Not across tenants. Mapping templates that learn from your sheets are scoped to your tenant only. We do not aggregate customer data into shared models. Optional features that would require cross-tenant aggregation are opt-in with explicit consent.
Can a borrower request deletion of their data?
Borrowers should route requests through the lender (you), since you are the data controller and we are the processor. We will support your deletion within the 30-day SLA codified in the DPA.
Privacy contact: security@ratestack.com