SECURITY & DATA

How RefundDesk handles your data.

Plain language. No filler. Everything a licensed customs broker needs to know before uploading client entry data.

Last updated: May 2026 · Questions: privacy@refunddesk.app

Infrastructure

Hosted on Render. Generated filing documents stored in AWS S3 (US East region). All other application data stored on Render's managed PostgreSQL. No data leaves US jurisdiction.

Encryption

All data in transit is encrypted via TLS 1.2 or higher. Data at rest is encrypted at the infrastructure level. Generated filing documents are stored in encrypted S3 object storage.

Access

Your account data and your clients' entry data are accessible only to you. RefundDesk staff do not access broker accounts or client data except to resolve a support request you initiate. No entry data is shared with third parties.

Third-party services

Stripe — payment processing. Receives only what is required to complete a transaction. No entry data transmitted.

Resend — transactional email delivery. Receives your business email address to deliver account and confirmation emails.

PostHog — product analytics. Receives page-level usage data on the authenticated application. Does not receive client entry data, IOR numbers, or duty amounts.

Retention

Account data and generated documents are retained for the duration of your account. Request deletion at any time by emailing privacy@refunddesk.app — completed within 30 days of account closure.

Attestation records are retained for 5 years from the attestation date per 19 CFR §111.23. These records constitute the legal record of your filing attestation and cannot be deleted during the retention period.

Audit architecture and record integrity

Every filing batch that a broker attests to produces a frozen calculation snapshot at the exact moment of attestation. This snapshot contains the duty principal, estimated refund, statutory interest, the literal arithmetic formula, the IRS Revenue Ruling that set the applicable rate, the eligible entry count, and the IEEPA HTS prefix set in effect — permanently bound to the attestation timestamp. It is never modified after write.

Attestation records include a tamper-evident version log maintained by the Logidze extension for PostgreSQL. Logidze operates at the database trigger level — every field-level change to an attestation record appends a new timestamped version to an append-only log, independent of the application layer. This log cannot be suppressed by application code.

The admin audit dashboard continuously compares live recalculations against each frozen snapshot and flags two types of divergence: bucket divergence (current eligibility classification differs from what was frozen) and prefix divergence (the active IEEPA HTS prefix list has changed since attestation). Divergence is logged and surfaced for review — the attested snapshot is never modified in response.

A unique database constraint enforces one attestation per filing batch — a batch cannot be re-attested or have its attestation replaced.

Given a filing batch ID or entry number, the audit dashboard can surface: the attesting broker's email, IP address, and timestamp; the verbatim attestation statement; the complete calculation snapshot with plain-arithmetic formulas; the IRS Revenue Ruling for each interest rate; the IEEPA prefixes active at attestation; any post-attestation divergence; and the full version history of the attestation record. No reconstruction is required — all records are sourced directly from the database.

Questions

privacy@refunddesk.app

For full data handling terms, see our Privacy Policy →

For the broker attestation guide, see What happens when you attest →

← Back to RefundDesk