BankerPipeline is designed with bank-grade security from the ground up — encrypted data, role-based access, and a hosting stack that meets the compliance bar your institution requires.
All customer and loan data is stored in a managed, enterprise-grade PostgreSQL database — never on commodity or self-hosted infrastructure.
BankerPipeline runs on Neon, a fully managed serverless PostgreSQL platform. Neon provides automatic backups, point-in-time recovery, and handles all database maintenance — no manual patching required.
Sensitive borrower data — SSNs, tax IDs, date of birth, income — is encrypted at the field level using AES-256-GCM before it's written to the database. Even a direct database read returns ciphertext, not plaintext.
Borrower-uploaded documents (tax returns, pay stubs, financial statements) are stored in Cloudflare R2 — an S3-compatible encrypted object storage service. Files never pass through your bankers' workstations.
All communication between users and BankerPipeline is encrypted. HTTP requests are redirected to HTTPS. Modern TLS protocols only.
BankerPipeline runs on Render, a SOC 2 Type II compliant cloud platform used by thousands of production applications.
Render is SOC 2 Type II certified, meaning an independent auditor has verified their security, availability, and confidentiality controls annually. Your data is hosted in the same infrastructure trusted by thousands of enterprise applications.
Every HTTP response from BankerPipeline includes a full suite of security headers to protect users from common web vulnerabilities.
Bankers and borrowers authenticate through entirely separate systems with different token namespaces. A borrower token cannot be used as a banker token — ever.
Bank staff authenticate via email/password or Microsoft SSO. Passwords are hashed using bcrypt with 10 rounds — they are never stored in plaintext.
Borrowers access the portal via a separate login flow. Their tokens carry a type: "borrower" claim — the API explicitly rejects banker tokens on borrower endpoints, and vice versa.
When a borrower uploads a document, the upload URL is a one-time HMAC-signed token scoped to that borrower and that document request. The token expires after use and cannot be reused or shared. This prevents unauthorized uploads and ensures documents land in the correct loan file.
Every banker has a role. Every role has defined permissions. Data visibility is further restricted by branch — bankers only see what they're assigned to.
Access is controlled at the feature level based on role. Roles cannot be self-assigned — only admins can grant or change roles.
Database queries are scoped server-side based on the authenticated user's branch. Frontend filtering alone is insufficient — BankerPipeline enforces data isolation at the query level.
Each bank or institution is a completely isolated organization. No data crosses organizational boundaries — queries are scoped to org_id at the database level, not the application layer.
Security-sensitive actions — login, permission changes, data exports, user deactivation — are written to an immutable audit log with user ID, timestamp, IP address, and action detail.
BankerPipeline is built with GLBA Safeguards Rule and common banking compliance requirements in mind — not bolted on after the fact.
Field-level encryption for PII, role-based access controls, audit logging, and HTTPS enforcement are all aligned with the FTC's Safeguards Rule requirements for financial institutions.
Render (hosting) is SOC 2 Type II certified. Neon (database) and Cloudflare R2 (documents) are enterprise-grade platforms with independent security programs. You're not on shared consumer infrastructure.
Role-based access control, branch scoping, and org-level isolation ensure users can only access what they need. This aligns with NIST and SOC 2 CC6.3 least-privilege principles.
AES-256 encryption at rest (database and object storage), TLS 1.2+ in transit, and AES-256-GCM field-level encryption for sensitive PII. Key versioning supports rotation without downtime.
Separate JWT namespaces for bankers vs. borrowers, 7-day token expiry, and server-side token type validation prevent cross-session attacks and unauthorized access.
Common exploit paths (/.env, /.git, WordPress probes) are blocked at the middleware level. This reduces attack surface and keeps your security logs clean from automated noise.
Key security properties for your compliance team's evaluation.
| Control Area | Technology / Approach | Status |
|---|---|---|
| Data encryption at rest | Neon PostgreSQL (AES-256), Cloudflare R2 (server-side encryption) | ✓ Active |
| Data encryption in transit | TLS 1.2+, HSTS, HTTPS-only (301 redirect) | ✓ Active |
| PII field-level encryption | AES-256-GCM per field (SSN, Tax ID, DOB, Income) | ✓ Active |
| Password storage | bcrypt (cost 10) — no plaintext storage | ✓ Active |
| Session management | JWT (HS256, 7-day expiry), separate banker / borrower namespaces | ✓ Active |
| Single sign-on | Google OAuth 2.0, Microsoft OAuth 2.0, SAML 2.0, OIDC | ✓ Available |
| Role-based access control | Admin / Manager / Banker / Viewer — feature-level permissions | ✓ Active |
| Branch data scoping | Server-side query filtering by branch_id and org_id | ✓ Active |
| Document upload security | One-time HMAC-signed tokens, 20MB limit, Cloudflare R2 | ✓ Active |
| Audit logging | Immutable per-org audit trail — login, permission changes, data changes | ✓ Active |
| Hosting compliance | Render (SOC 2 Type II), Neon, Cloudflare R2 | ✓ Active |
| Security headers | HSTS, CSP, X-Frame-Options, X-XSS-Protection, Referrer-Policy | ✓ Active |
| GLBA Safeguards alignment | Encryption, access controls, audit trail, HTTPS, PII protection | ✓ Aligned |