Security

What FundStamp does to protect the data it holds, described so it can be checked rather than trusted. This is not a compliance attestation: FiBase Inc. holds no third-party security certifications, and says so rather than letting the absence be assumed either way.

Effective September 7, 2026.

Credentials

FundStamp never receives institution usernames or passwords. Those are entered inside Plaid’s own interface. The access token Plaid returns is used, inside the same request, to read balances and holdings, and is then revoked; it is never stored, never sent to a browser, never returned by an API route and never written to logs. There is no column for it.

Second factor

Before any session can open the bank connection or exchange what it returns, the account holder must satisfy a second factor: a passkey (WebAuthn, unlocked the way they unlock their device) or a time-based code from an authenticator app. Both routes that touch Plaid refuse a session that has not, so the requirement holds even for a request that skips the screen. The step-up is per session and per device. Authenticator secrets are encrypted at rest with a key held outside the database, so a copy of the database cannot generate codes. Eight single-use recovery codes are shown once at enrolment and kept only as hashes.

Monitoring

FundStamp keeps its own access log: every sign-in link requested and used, every passkey registered and used, every authenticator code accepted or refused, every recovery code spent, every administrator page opened, and every refusal at the routes that reach a bank. Addresses and email addresses are stored as hashes, never in the clear. The log is kept for ninety days, reviewed by the administrator, and summarised nightly to an alert address whenever a day needs a look: a burst of refused codes against one account, a run of failed sign-in links, or a housekeeping job that did nothing. Google Workspace alerts on suspicious sign-ins to the company’s own accounts separately.

Authorization

Every protected route checks the session server-side before rendering. Buyer-facing database queries additionally run under PostgreSQL Row Level Security as a restricted role, so a query that forgot its ownership filter would still return nothing.

Verification links

Link tokens are generated from a cryptographically secure random source and carry roughly seventy bits of entropy, which makes guessing a live link impractical. Verification pages are excluded from search indexing, are rate limited, and can be revoked or allowed to expire by the account holder.

Bank access

FundStamp never receives institution credentials: they are entered inside Plaid’s own interface. The access token Plaid returns is used to read balances and holdings and is then revoked within the same request, so no bank access token is stored at any point. A compromise of the FundStamp database cannot yield access to anyone’s accounts.

Personal data

FundStamp performs no government-ID check against any authority or database, and holds no identity documents and no biometric data. The name it stores is the one the account holder typed for display.

One document type is read without being held: where a buyer asks an equity investor to show they are a different person, the investor uploads something with their name on it, it is compared against the buyer’s name inside the request, and the file is destroyed before the request returns. What survives is a single yes or no. Nothing is written to disk, nothing reaches a backup, and no model is asked to interpret it.

Payments

FundStamp takes no payment from the people who use it, so no card details are collected, transmitted or stored, and there is no payment surface to attack.

Known limitations of this build

• Rate limiting is in-process and therefore per-instance.
• There is no key rotation process and no intrusion detection. The hosting platform’s own request logs are not retained beyond its short default window; access is logged at the application instead, as described under Monitoring.
• No penetration test or third-party security review has been performed.

Reporting a vulnerability

If you believe you have found a security problem in FundStamp, write to us at the address below or through the Support link at the foot of any signed-in page, with enough detail to reproduce it. We will acknowledge within one business day and will not pursue anyone who reports in good faith, gives us reasonable time to fix the problem, and does not access, alter or retain data belonging to anyone else.