Built on a foundation of security

Practices that handle client banking documents don’t need security as a feature. They need it as a baseline. DocGenie was designed around that requirement from the first commit.

This post covers the principles. For the specific protocols and how each layer maps to a real attack surface, see Bank-level security for client financial documents.

Secure-by-default, not bolted on

Security framing matters because the alternative is treating it as something to add later, when it’s already too expensive to retrofit. DocGenie’s code, infrastructure, and access patterns were built with security defaults at every layer, not as an audit-driven afterthought. That choice constrains what gets shipped and accelerates what’s safe to ship.

OAuth-based authorization, not credential sharing

Clients authorize access through their institution’s official authorization flow. Their password never leaves their possession, never gets stored in DocGenie, and never moves through any system the bookkeeper controls. Access can be revoked any time without contacting the practice.

That single decision removes the largest class of operational risk for practices that handle client banking documents: shared credentials sitting in password managers, email threads, or sticky notes.

Delivery into governed storage you already control

DocGenie doesn’t hold client documents in its own data lake. Files are delivered into the cloud storage your firm already uses (Google Drive, OneDrive, Box, Dropbox), under the access controls you already manage. The working copy of a client’s records lives where your governance policy already applies.

The result is a smaller blast radius. A compromise at any single layer doesn’t unlock the entire chain.

SOC 2 aligned

DocGenie is aligned to the SOC 2 framework: documented controls, role-scoped access, and audit logs that record every document access and retrieval. Alignment is operational as much as legal. You can see who touched a client’s records, when, and from where, without reconstructing it after the fact.

(Aligned, not certified. The distinction matters. We follow the framework’s controls; we have not yet completed a Type II audit. The path is in progress.)

Monitoring, alerts, and the unglamorous work

Security isn’t only prevention. Infrastructure is continuously scanned for vulnerabilities. Engineers are alerted to anomalies. Audit logs are retained and reviewable. Staff go through background checks. Access is reviewed quarterly.

Most of this is table stakes for any vendor handling client financial data. We list it because the industry standard for security disclosure is a checkmark on a marketing page, and we’d rather name what the work actually looks like.

Cyber insurance, as a backstop not a substitute

We carry cyber liability insurance as a backstop against the worst case. It is not a substitute for the controls above, and we don’t think of it that way. The order is: prevent, detect, respond, then recover. Insurance covers the recovery layer.

What this means for practices considering DocGenie

Security posture is the kind of thing that’s only legible after something goes wrong. The decisions we made during the build, like authorizing access without asking clients to share their bank passwords, delivering into your governed storage instead of ours, and aligning to the SOC 2 framework from the start, are what determine how the system behaves under stress.

If you’re evaluating DocGenie alongside other tools, ask each of them where the client’s banking credentials live, where the retrieved documents live, and what audit trail you can produce in the event of a question. The answers separate the operationally serious tools from the rest.

For the technical depth on each layer, see Bank-level security for client financial documents.