Security Overview

When you upload a file we read its column headers and refuse these outright. They are never mapped, never offered to you in a picker, and never reach our servers:

Free text is scrubbed as well, in the browser before upload and again on our server, because the server never trusts the client. Anything shaped like a Social Security number, a card number, a long run of digits or a phone number is replaced, and the sentence around it survives so the finding does. The same scrubbing applies to every free-text field an employee types.

What we do hold: your organization structure, your roster (name, title, work email, team, and who they report to), the feedback you upload, an account for each user, and a security log. Uploaded files are parsed in your browser, and no uploaded file is ever written to disk on our servers.

Inside your institution, a manager sees only their span of the org chart. That is enforced on the server for reads and writes alike, not merely hidden in the interface.

Invite-only. An administrator invites staff from the roster. Each invite is a single-use link bound to that person’s email address and expires in seven days. One login belongs to exactly one institution, and every user type has a login, so there is no anonymous or link-only access to any page showing bank data.

Passwords and a second factor. Twelve characters minimum, with a capital letter and a special character. Every new password is checked against Have I Been Pwned using k-anonymity, so only the first five characters of its hash ever leave our server and the password itself never does. Passwords are stored by the authentication service as salted bcrypt hashes and are never visible to Custavox. After a correct password, a six-digit code is emailed to the account address and must be entered before the session opens. It is asked on every sign-in, not once per device, and has been on for every user in production since September 7, 2026.

Three roles, chosen by you, never inferred from the org chart:

You can instead grant a manager the whole bank, or hand-pick the branches and departments they see. Every write is guarded by a capability check on the server. The interface disables the same controls, but the server is what decides, and an automated check fails if a write is ever added without a guard. Refused attempts are recorded with the actor and the reason.

Deactivating someone ends their access on their next request and keeps their history so the log stays attributable. An institution’s last administrator cannot be removed or demoted, and nobody can deactivate themselves.

• HTTPS only, with HTTP redirected and strict transport security set for two years across every bank subdomain. Certificates rotate automatically, and DNS records limit which authorities may issue them.
• Locked-down response headers: a default-deny content policy, no framing by any other site, no MIME sniffing, a restrictive referrer policy, and camera, microphone, geolocation, payment and USB all denied.
• Short-lived signed access tokens, verified locally on every request against the service’s public key, so a forged or expired token is refused before any of our code runs. Refresh tokens rotate.
• Sessions end after a day of inactivity and after thirty days regardless. Signing out invalidates the session immediately.
• The database connection is always encrypted. The database refuses unencrypted connections, and we verify its certificate against the provider’s root on every connection.
• Your browser stores only interface preferences, such as a theme or a column choice. No bank data is cached beyond the page being viewed.

SPF and DKIM are published for the sending domain, and DMARC is published with an enforcing policy. The apex domain declares that it sends no mail at all, so anything claiming to be from it fails authentication.

Invitations carry a single-use link. Sign-in codes carry a code and nothing else, no link and never your password. Notifications carry a title, a count and a link back into the app, never customer comment text.

Everything that decides whether an opportunity exists at all, including the grouping, the thresholds, the routing and every dollar figure, runs in our code, not in the model.

The controls on its output are structural rather than advisory:

• It fills a fixed schema. It cannot take actions, call tools, browse, or write free-form content that reaches anyone.
• It never writes numbers. Every count and dollar figure you see is rendered from your data by our code. A write-up containing a digit is held back rather than shown.
• It may only name what its own evidence names. A card mentioning a branch, person, system or product the evidence doesn’t link to is held.
• Quoted text is data, never instructions. Every request tells the model that customer and staff text is verbatim evidence, and that any instruction inside it is part of the complaint rather than something to obey. This is a second layer; the controls above are what actually stop a hostile review doing anything.
• Nothing is sent by the AI. A recognition email is a draft until a person at your bank reviews it, edits it and presses send. There is no auto-send.
• The model’s original is frozen and every human edit recorded, so you can always see what it proposed against what was accepted.

It runs only when new feedback is imported and once after initial onboarding, never on a page view, and only after enough of your roster has completed their questionnaire for the analysis to mean anything. Every call is logged and rate-limited. Under Anthropic’s commercial terms, what we send is not used to train their models; they retain API inputs and outputs for a limited period for abuse monitoring, and zero-retention handling can be arranged for an institution that requires it.

It covers role changes, deactivation and removal, invitations created and accepted, sign-ups, second factor passed or failed, password resets and changes, logins deleted, notification rules changed, institution settings changed, organization records deleted or duplicated, feedback imported and deleted, opportunity cards deleted or released, recognition emails sent and archived, data exported, Custavox staff access granted or revoked, and every refused attempt to do something a role is not allowed to do.

Each entry carries the actor’s id, email and role at the time, the target, a readable label frozen at write time, an IP address, a browser user-agent and a timestamp. Logging never fails the action it records, because a logging error must not block a delete, and an automated test fails if any sensitive write stops logging.

Staff access is a named list of individual logins. Every grant and revocation is logged, the last staff administrator cannot be removed, and nobody can revoke their own access. Staff logins follow the same password, breach-screening and second-factor rules as yours.

Staff can read an institution’s data to provide support and to tune the analysis, for example replaying a scan to see why a card was held. Staff do not use your workspace as one of your users: a staff login is sent to an internal portal, which never renders on your subdomain. Anything staff do to your data is recorded in the same log you read.

• Backups are managed by the database provider, daily, and encrypted at rest. Volumes and backups are encrypted with AES-256.
• Export is self-service. An administrator downloads the institution’s complete data as a single JSON document, with invitation secrets stripped. Rate-limited and logged.
• Deletion is self-service too. An administrator types the institution’s name to confirm, and one cascading delete removes every row it owns. An automated test proves it, by creating a throwaway institution, deleting it, and checking every table for survivors.
• What survives, deliberately: individual logins, because they belong to people rather than the institution and can be deleted separately, and the security log above.
• Afterwards, data is gone from the live database immediately and ages out of encrypted backups on the provider’s schedule.

Those help an attacker more than they help a reader. A published threshold is one an attacker can pace underneath, and a published redaction rule is one they can write around. Withholding them is part of the control, not a gap in it.

We would rather tell you what we are holding back, and why, than let you find the gap and wonder.

Vercel, Supabase, Resend and Anthropic each hold a SOC 2 Type II attestation, and their reports are available from them under NDA. Custavox does not hold a SOC 2 report of its own today, and we don’t claim theirs as ours.

Separately, our source code is hosted on GitHub, which holds no bank data of any kind. We list it because a thorough supply-chain review will ask.

A single automated audit runner covers secrets, authentication, database exposure, input handling, cost abuse, response headers, live probes against the production site, mail DNS, dependencies and operations. It runs before every deployment and monthly against production, and findings and their resolution are kept in a dated log.

Separate automated tests cover the tenant guard on every server action, the role matrix on every write, the audit log on every sensitive write, the delete cascade, the export, subdomain routing and the rate limiter.

Your review will have questions this page doesn’t answer, and some of them are things we deliberately hold back. Call (515) 460-4911 and we will send the full document.

If you believe you have found a security problem, call the same number or reach us through our contact page. We acknowledge within two business days and keep you informed until it is resolved.

See also our Privacy Policy and Terms of Service.