What we hold, and how we hold it.

The application, the Postgres database and the scheduled jobs all run on Render, in its Virginia region. Uploaded documents are stored in Amazon S3, in us-east-1. Both are in the United States, and nothing is replicated outside it.

Every firm’s data sits in one database and is logically isolated: each query is keyed to the organization the signed-in person belongs to, and there is no path that takes a customer’s id from one firm and answers with another firm’s row. That is not a convention we hope holds — it is a set of tests that fail the build, including one that walks the source and refuses any new code that reads documents outside the authorization resolver.

One exception, and it is ours rather than a customer’s: the platform owner’s console reads across firms — it is how a support request gets answered and how the platform is billed and operated. It is reachable only by the platform operator’s own account, no customer role can reach it at any permission level, and signing in to a workspace from it is impersonation: the start is refused unless it can be recorded in the firm’s audit log, and the stop is recorded on a best-effort basis so a failed write can never strand somebody inside a workspace that is not theirs.

Traffic between your browser and the application, and every connection from the application to an outside provider, is encrypted with TLS; the database sits on the hosting provider’s private network beside the application. Both Render and S3 encrypt what they store at rest. On top of that, the values that would matter most if a database copy ever escaped are encrypted a second time in the application itself, with AES-256-GCM: taxpayer numbers, investor bank routing and account numbers, credit report data, message bodies, and the API tokens a firm gives us for its own email and e-signature accounts.

Those keys carry version identifiers, so a key can be replaced without losing what the old one wrote: the new key goes in, the old one moves to a previous-keys list, and a sweep rewrites every encrypted value under the new key before the old one is retired.

Card details never reach our servers. Paying happens on Stripe’s own hosted checkout, and what comes back to us is a subscription status, not a card number.

Staff access is a permission grid, not a job title: roles are defined by the firm, and every action in the product is registered against the permission it requires — a test fails the build if an action is ever added without one. Individual loan files can be restricted to a named team, and documents can be shared deliberately rather than by default.

Bank details and taxpayer numbers are masked on screen. Revealing one asks the person for their password again — plus their second factor if they have one — and writes an audit row naming who looked and when.

Staff and investors can turn on two-factor authentication with an authenticator app. A firm can require it of all its staff; investors enrol for themselves, on their own accounts. Borrower and investor portal sessions expire on a rolling window and again at a hard maximum, so a sign-in left open on a shared computer does not last indefinitely.

Sign-in attempts and password resets are rate limited on every door — staff, the borrower portal and the investor portal — and so are the forms a stranger can reach: the apply form, borrower upload links, contractor invoice links, the post-funding inquiry form and investor confirmation replies. Sensitive actions are written to the firm’s own audit log, which ships in the firm’s export — and that includes us: if we sign in to a workspace to help with a support request, the borrowed session carries a banner the whole time. The start is refused unless it can be recorded in that firm’s audit log — in every firm the borrowed account belongs to, in one transaction, so a session that began is a session every one of those logs names. The stop is recorded on a best-effort basis, because a log write that fails on the way out must not strand an operator inside somebody else’s workspace.

A file is accepted only when its own bytes identify it as one of a short list of formats — what the browser claims about a file is never trusted, and the extension has to match what the contents turned out to be. Text and CSV uploads are read in full and refused if they carry web markup; Word and Excel files are checked as valid Office packages. Uploads have a size ceiling, and a stored document can be quarantined so nobody can open it while a question is being answered.

Mail goes out through Postmark. A firm sends from its own verified domain once it has proved it owns it — a DKIM record so Postmark may sign for the domain, and a Return-Path record so bounces come back to the right place. A firm can also move to a sending server of its own, which gives it a private suppression list; until it does, its mail goes through the platform’s server, whose suppression list is shared with the other firms on it. Bounces and spam complaints are recorded, suppress further sending to that address, and are shown to the firm so it can fix a bad address instead of quietly failing.

The database is backed up by Render’s managed Postgres service on that plan’s own schedule, and a daily Render job keeps a second copy away from the provider for 35 days. The document bucket has versioning switched on, so a file deleted or overwritten by mistake can be recovered for 90 days.

Deletion is deliberately slow: when a workspace is scheduled for deletion the date is 30 days out, the owner can cancel it at any point before then, and only after that does a nightly job remove the rows and every version of the files from live storage. The copies taken before that night are not reachable by that job, and we would rather say so than imply otherwise: the provider’s snapshots roll off on its schedule, and our own dumps expire 35 days after they were written. A deleted workspace ages out of the backups; it does not vanish from them the same night.

An owner or an administrator can request a full export of the workspace, whenever they like, from Settings › Exports & data — no request to us, no waiting. Every export comes with a manifest listing what is in it, what was masked and what was excluded for security, so nothing is missing without being named. Deleting the workspace is self-service too: it clears every version of your files from live storage at once, and the backup copies already taken age out on the clocks above.

If a subscription lapses, the workspace stays readable and exportable for 90 days before anything is scheduled for removal. Nobody loses their records because an invoice was missed.

These are every company that can see customer data, what each one does, and where it runs.

Render

Application hosting, the managed Postgres database and the scheduled jobs that run the product. United States

Amazon Web Services S3

Storage for every document uploaded to a workspace — applications, statements, signed files. United States

Postmark

Delivery of the email the product sends: invitations, document requests, reminders and confirmations. United States

Stripe

Subscription billing. Card details are entered on Stripe and never reach our servers. United States

OpenAI

The AI setup assistant, automation-rule drafting, stage-checklist drafting and import column mapping. The import mapper sends the worksheet’s name, its column headers and a few sample rows, with tax ids, account numbers and similar values masked first — the sheet name included; the setup assistant sends the description an administrator typed and nothing else; the two drafting features send the request an administrator typed plus the firm’s own file-role names, and rule drafting also sends the internal id of each of those roles so a drafted rule can point at one. A borrower file is never sent. United States

Xactus

Consumer credit reports, ordered under the lender’s own Xactus account. United States

EsignCenter

Electronic signature — a service we operate ourselves on Render. Signed documents and audit certificates are filed back into the customer’s workspace. United States

The full list of service providers is in our Privacy Policy, with what each of them is allowed to do.

Four things a security reviewer will ask for and we cannot hand over today:

• Single sign-on. There is no SAML or SSO integration; people sign in with a password and, if they turn it on, an authenticator app.
• An audit report of our own. The platforms we run on hold theirs; we have not been through an audit ourselves.
• A penetration-test schedule. We have no regular outside testing cadence to point at.
• A public status page. Service problems are communicated by email, not on a dashboard.

All four are on the roadmap, in roughly that order, and this page will change when they are real rather than when they are planned.

Write to evan@processorteam.com. Tell us what you found and how to reproduce it, and you will get a human reply — we would far rather hear it from you than read about it later.