Look without being watched. Share without being sold.
Seven disclosures on what happens to your personal and financial data here — each with the sentence you can hold us to, how the system does it, and the rule it rests on.
- We believe you should be able to ask any financial question without becoming someone's data.
- We believe understanding a product should never cost you your privacy.
- We believe your financial information reaches a participating, licensed partner only when you authorize it.
That's why we built DuckWater: a private place to learn, compare and navigate financial products on your own terms.
Five things you can count on
- You can look without being watched — no account to explore, and our calculators do not post your inputs to a server.
- No AI vendor receives your data today; when AI touches a file, your identifiers will be removed first.
- Your file moves once, to one licensed institution you chose, with your consent stored word for word.
- You can take it back: cancel a crypto-bridge credential yourself, ask us to revoke a sharing consent, and nothing more moves on it.
- We are building for the decade your data has to survive: we plan to move to post-quantum encryption ahead of NIST's transition timeline — and we say how far along we are.
Browse products without being profiled
You can explore every product, calculator and guide on DuckWater without creating an account, and we do not build a profile of you while you do.
How it works
- Product pages, calculators and guides are public and need no account. Calculators are illustrative: they compute only on the numbers you type, and that arithmetic runs in your browser — our calculator code does not post your inputs to a server.
- We do not run advertising trackers, session-replay vendors or cross-site identifiers on our public pages. The bot check on our forms is the third-party script we know we load; we are adding an automated check that fails the build if another one appears.
- On the crypto bridge you can start a file before giving us contact details: the system holds only a random key made in your browser, stores only a one-way hash of it, and stores no wallet or exchange identifier, no exact balance and no score — there is no column for them, every stored string on that path is checked for a clear-text identifier, and our tests try to smuggle one in.
No AI vendor sees your data — and when AI touches a file, your identifiers will be removed first
DuckWater sends nothing about you to an AI vendor today: the assistant on this site is scripted, and no server path calls an AI model. When AI is added to files, it will sit behind a redaction shield that replaces your identifiers with placeholders before any model is asked a question, and documents will be blacked out at the pixel level on a machine we control.
How it works
- Today: the Duck assistant answers from a fixed script and your messages to it are not sent to any model. There is no AI-vendor integration in the codebase.
- Planned, and published here only when it lands: a four-stage shield on every model call — scan, redact, dispatch, rehydrate — that swaps Social Security numbers, phone numbers, email addresses, licence, account and loan numbers, card numbers and dates of birth for typed placeholders, keeps the placeholder-to-value map in a short-lived, memory-encrypted vault that expires on a timer and is destroyed when the answer is put back together; and a document redaction service that only answers on the local machine and burns black boxes over the words themselves rather than overlaying them.
- Until that lands, the protection is simpler and absolute: nothing is sent.
Encrypted in transit and at rest; matchable identifiers stored only as keyed hashes
Your connection to DuckWater is encrypted, our database provider encrypts what we store at rest, and on the crypto bridge the identifiers that must be matched are stored only as keyed one-way hashes that cannot be reversed without a key we hold.
How it works
- In transit: the site is served over HTTPS from our hosting provider's edge network; we do not serve plain HTTP. We plan to verify and record here the minimum TLS version and whether that edge negotiates a hybrid post-quantum key exchange (X25519 + ML-KEM) for your browser, and we plan to move our own application-layer envelopes to that construction (see D-7).
- At rest: our database provider encrypts stored data. DuckWater does not yet add its own field-level encryption on top; that is in progress and will be stated here when it is live.
- On the crypto bridge, the subject key and any identifier that must be matched are stored only as HMAC-SHA-256 under a server-held key — keyed hashing, not bare hashing. A bare hash of a public identifier can be ground out by brute force; a keyed hash cannot be reversed without the key.
- In progress: a cryptographic inventory generated from the code — every algorithm, key length and library — so any one of them can be swapped without redesigning the system. Until it exists we do not claim crypto-agility.
Your file moves once, to the institution you chose, with your consent on record
DuckWater is a technology platform. We do not lend and do not decide. With your consent we transfer your file to one participating, licensed institution, which originates under its own licence. The transfer is preceded by a consent record that stores the exact words you agreed to, and no hand-off can be written once that consent is revoked.
How it works
- Consent is a first-class record: the disclosure text verbatim (not a version number), the time, and a revocation timestamp. The partner hand-off checks that a usable, unrevoked consent exists before it is written.
- On the crypto bridge, every consent, credential and revocation also produces a receipt: canonical, hash-chained from a fixed starting value and signed by our attestor key, written in the same transaction as the referral so no path yields one without the other. A receiving institution can verify that chain offline. Extending receipts to every hand-off path, and sealing the hand-off payload to the institution's own key, is in progress.
- Our institution connectors are built with separation of duties: the code that prepares a hand-off never sees financial fields, inbound status messages may only be verified and normalised, and no connector decides anything about a person. Compensation fields are mapped out at a single point and can never reach a customer-facing view or ordering.
- Availability is per state and per partner. On the crypto bridge a per-state gate is checked before any partner list is consulted; a state that is off is off for everyone.
Revoke, and nothing more moves
On the crypto bridge you can cancel your credential yourself, at any time, and the cancellation is written into the same signed receipt chain as the grant. Consent to share a file with a partner is withdrawn by asking us; once it is marked revoked, no further hand-off can be made on it. A self-service path that withdraws consent and deletes what we hold about you is in progress.
How it works
- Today, self-service: the crypto-bridge revoke control cancels every active credential tied to your key and writes a revocation receipt into the signed chain. Re-issuing a credential revokes the prior one automatically. This cancels the credential; it does not by itself mark your sharing consent revoked.
- Today, on request: consent to share a file is marked revoked by us, with a timestamp. Any hand-off that checks consent refuses a revoked one. The record of the grant itself is kept, because a regulator's question is "what did they agree to, and when did it end".
- Scheduled jobs trim the audit trail to its retention window, expire credentials, delete lapsed signing challenges and purge rate-limit windows.
- In progress: a self-service path that marks consent revoked and deletes what we hold about you — leaving only the signed consent and revocation receipts, a hash and a signature with no personal data — and honours deletion rights under applicable state law through the same control.
- A limit we state plainly: revocation stops any further transfer — it does not by itself remove what DuckWater holds (the in-progress deletion path above is what removes our copy), and even that deletion cannot recall a file already transferred to an institution. That transferred copy is governed by the institution's own obligations, which is one reason the transfer happens once, to one institution, only on your recorded consent.
Not sold, not fed to data brokers, not used to train AI
We do not sell your data. We do not share it with data brokers, advertisers or lead resellers. No AI vendor receives it today, and when one does it will be under zero-retention, no-training terms and will only ever receive redacted text.
How it works
- Today there is no AI-vendor integration, so the question of what a vendor retains does not arise. Before one is added: zero-retention, no-training terms executed with the provider, the matching provider-side setting switched on, and the provider listed here with the agreement date. Our dispatch code will refuse any provider without those flags.
- Changes made through our admin and partner workflows are recorded as events, written inside the same transaction as the change — so rolled-back work leaves no false entry — and readable only by role. No event row is ever rewritten; scheduled jobs trim the trail to its retention window, so it is immutable for as long as we keep it. A signed-in caller's identity is resolved on the server and overrides whatever the request claims; our own server supplies the author for the few actions that happen outside a database write, such as a CSV export, and nothing else can.
- A partner hand-off requires a consent record, and the parties a file is shared with are the participating, licensed institution you chose and the builder partner whose job it is — and a builder partner sees status, never the file.
Built for the decade your data has to survive
Data encrypted with today's common methods can be recorded now and decrypted later by a quantum computer. A Social Security number or a mortgage file is as sensitive in 2036 as in 2026. DuckWater plans to move its key exchange and signatures to the NIST post-quantum standards on a schedule ahead of NIST's transition timeline for federal systems (deprecation after 2030, disallowance after 2035), and says on this page exactly how far along that is.
How it works
- The threat is called harvest-now-decrypt-later: an adversary captures encrypted traffic today and waits. The U.S. Federal Reserve, the G7 Cyber Expert Group, the Bank for International Settlements, Europol's Quantum Safe Financial Forum and the White House all treat it as a present risk.
- The timeline: NIST's draft transition guidance for federal systems (IR 8547) deprecates RSA-2048 and P-256 after 2030 and disallows quantum-vulnerable public-key cryptography after 2035; it is the benchmark we measure ourselves against, not a rule that binds us. Published estimates of the machine needed to break RSA-2048 fell from twenty million noisy qubits (2021) to under one million (2025).
- Where we are: signatures on the crypto bridge are Ed25519 and keyed hashes are HMAC-SHA-256, both classical. Nothing DuckWater runs today is post-quantum at the application layer. The plan is hybrid X25519 + ML-KEM for envelopes and dual Ed25519 + ML-DSA signatures for receipts, so a receipt verifiable today stays verifiable afterwards; each piece is stated here only when it is live.
- Why it matters to the institutions we hand off to: if the years a file must stay secret plus the years it takes to migrate exceed the years until a capable quantum computer, the migration is already late. A mortgage file retained for decades fails that test under every published expert timeline.
What this page will never say
- A rate, APR, payment, term, LTV or coverage threshold.
- A partner, licence, certification or award we do not hold — no “bank-grade”, “SOC 2” or “quantum-proof” without the certificate in hand.
- A credit check we do not perform, or availability we do not have in your state.
- That encryption is “unbreakable”. The honest claim is the algorithm, the parameter and the standard it meets.
- That we never store your data. We store it, encrypted, for the time a hand-off needs — and we say so.
The controls behind these disclosures — Security & compliance. What we are, and what we are not — Licenses & disclosures.