BankerPipeline was built with financial institution security requirements from day one — TOTP 2FA (RFC 6238), SSO/SAML 2.0, OIDC, AES-256-GCM field-level encryption for all PII and HMDA demographic data, role-based access control, GLBA Safeguards alignment, a unified audit log with examiner quick-views, and concentration limit monitoring. Every control is documented for your IT security and compliance review.
Multi-layered protection from login through session expiry — including SSO/SAML 2.0 and OIDC for institutional identity providers, TOTP-based 2FA, brute-force lockouts, JWT algorithm hardening, and strict role-enforcement middleware.
Organizations can authenticate through their existing identity provider using SAML 2.0 or OpenID Connect (OIDC). Banker credentials are managed centrally — provisioning, deprovisioning, and MFA policy stay within your IdP.
TOTP-based 2FA via Google Authenticator, Authy, or 1Password. Admins can enforce 2FA org-wide; individual user resets are handled through the admin console. MFA enrollment itself is rate-limited to prevent brute-force bypass during setup.
Account lockout after 5 failed login attempts with a 15-minute cooldown. Progressive delays on repeated failures. Error messages don't reveal whether the account exists.
Minimum 8 characters with mandatory uppercase, lowercase, number, and special character. Enforced at registration and on every password change. Password strength indicator shown in real time.
Tokens use HMAC-SHA256 and are issued with a strict algorithm allowlist. The algorithm confusion attack vector (alg: none / RS256-to-HS256 downgrade) is closed — only HS256 is accepted. Tokens rotate automatically on sensitive actions and expire per policy.
Admin and manager middleware use explicit role allowlists — not a "not-unauthorized" check. A decoded token missing the role field cannot bypass access controls. Default role at registration is the least-privilege assignment.
Bank staff authenticate via email and password (or SSO). Passwords are hashed with scrypt — industry-standard with unique per-password salts. JWT tokens carry explicit type claims to prevent cross-auth attacks.
type: "banker")Borrowers access the portal through a separate, fully isolated authentication system. A borrower token cannot authenticate as a banker — the API validates token type on every request.
type: "borrower" claim enforced server-sideFour roles with distinct permissions. Data visibility is restricted by branch — bankers only see the records assigned to them. Every query is scoped server-side, not just filtered in the UI. Branch INSERT operations enforce org_id to prevent cross-tenant write gaps.
Access is enforced at the feature level. Roles cannot be self-assigned — only admins can grant or change roles within the organization.
Branch ID is embedded in the JWT at login. All database queries are filtered server-side — a banker cannot access records outside their branch, even if they tried. Branch creation enforces org_id at the INSERT layer.
Each institution is a completely isolated organization. Queries are scoped to org_id at the database layer — not delegated to the application layer to get right. Document sensitivity scoping is enforced at the record level.
Every authentication event, data change, permission change, and stage transition is logged with timestamp, user, IP address, and before/after values. The audit trail is append-only, searchable, and branch-filterable for regulatory exams.
Sensitive data is encrypted at the field level before it touches the database — including guarantor PII, participation partner contacts, referral source PII, and all HMDA demographic fields. Key rotation is supported without downtime. HTML escaping is applied wherever user-supplied content can reach output.
All personally identifiable information is encrypted with AES-256-GCM before it is written to the database. A direct database read returns ciphertext, not plaintext. Encryption coverage extends across all entity types.
User-supplied content that can reach rendered output is HTML-escaped at the point of storage and output. This covers letter template merge fields, demo email content, and SAML error responses — closing both stored XSS and reflected XSS vectors.
Borrower-uploaded documents (tax returns, pay stubs, financial statements) are stored in Cloudflare R2 — server-side encrypted object storage. Files never touch the application server or banker workstations.
User passwords are hashed using scrypt with a unique random salt generated for every password. This is not a single shared salt — even an attacker with database access cannot precompute scrypt hashes.
All traffic between users and BankerPipeline is encrypted in transit. HTTP is redirected to HTTPS. HSTS header set to 1 year including subdomains.
Production error responses are sanitized across all API routes. Database schema details, stack traces, and internal file paths are never returned to the client — they are logged server-side only.
Every API endpoint is protected against common attack vectors — rate limiting, MIME type validation, a hardened CSP with no unsafe-inline, CORS restricted to explicit origins, and a blocked exploit path list.
Every response includes a comprehensive set of security headers. The Content Security Policy is hardened — unsafe-inline is removed from script-src. Inline scripts that remain are nonce-protected.
Authentication endpoints are rate-limited to block credential stuffing attacks. MFA setup and verification endpoints have independent limits. Requests beyond the limit receive a 429 response with a clear retry window.
All API endpoints validate and sanitize input to prevent SQL injection and XSS. Request payloads are size-limited. File uploads validate MIME type server-side via magic byte inspection — not just file extension.
Cross-origin requests are blocked by default. The allowed origin list was migrated from a wildcard to an explicit allowlist — only BankerPipeline domains are permitted.
The borrower-facing portal is a completely separate security domain from the CRM. Borrowers cannot access banker views, banker data, or administrative functions — enforced at the API level, not just the UI. Construction draw submissions and closing worksheet views are scoped to the borrower's own loan only.
Two layers of isolation are enforced on every borrower request. Horizontal: borrowers can only access their own loan records. Vertical: borrower tokens are rejected by all banker and admin API endpoints.
type: "borrower") validated server-side on every requestBorrower sessions expire after 24 hours — significantly shorter than the 30-day CRM session window. This reflects that borrowers are occasional users, not daily staff, and that shorter windows limit exposure from shared or public devices.
Borrower document uploads are validated server-side before storage. File type allowlist, MIME magic byte inspection, path traversal blocking, and file size caps are all enforced at the server layer.
Borrower-accessible features — construction draw submissions, closing worksheet read-only views, and messaging — are scoped to the authenticated borrower's loan. No cross-loan access is possible regardless of URL manipulation.
BankerPipeline runs on Render, a SOC 2 Type II compliant cloud platform. Data is stored in Neon PostgreSQL — enterprise-grade serverless database with automatic backups and point-in-time recovery.
Render is SOC 2 Type II certified — an independent auditor verifies their security, availability, and confidentiality controls annually. Your data runs in isolated build and runtime environments.
Fully managed serverless PostgreSQL with automatic backups, point-in-time recovery, and no manual patching. Tenant data is fully isolated per organization at the query layer.
BankerPipeline was designed with GLBA Safeguards Rule compliance requirements in mind — not retrofitted after deployment. The Exam Prep Dashboard provides direct links to all examiner views, and the Unified Audit Log surfaces pre-filtered examiner quick-views for Admin Actions, Permission Changes, Failed Logins, Deletions, and Data Exports.
AES-256-GCM 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 is SOC 2 Type II certified. Neon PostgreSQL and Cloudflare R2 are enterprise-grade platforms with independent security programs — not shared consumer infrastructure.
Role-based access control, branch scoping, and org-level isolation ensure users access only what they need. Default registration role is viewer — least-privilege assignment. Aligns with NIST and CC6.3 principles.
AES-256-GCM field-level encryption for all sensitive PII across customers, guarantors, participation partners, and referral contacts. TLS 1.2+ in transit. scrypt password hashing. Key versioning supports rotation without service interruption.
Append-only audit log with 6-year retention and before/after snapshots. Examiner quick-views pre-filter for: Admin Actions (90d), Permission Changes, Failed Logins, Deletions, and Data Exports. Branch-scoped filtering for targeted regulatory exams. CSV export is chain-of-custody logged.
The Exam Prep Dashboard provides direct links to all examiner views from a single page. Compliance checklist with unified audit log card, 6-year retention confirmation, and pre-filtered examiner quick-view links — reducing exam preparation time.
Regulatory concentration limits — CRE/C&D concentration ratios and single-borrower exposure limits — are monitored in real time. Breach alerts are surfaced in the dashboard. Limits are configurable by administrators against bank capital.
HMDA LAR data — including race, ethnicity, sex, and age demographic fields — is restricted to users with appropriate roles. Demographic fields are encrypted at rest with AES-256-GCM. Access is logged in the audit trail.
Community Reinvestment Act data is access-controlled at the role level. CRA reporting data is restricted to authorized roles and all access is included in the complete audit trail.
Compliance exports — including HMDA LAR, CRA, and full audit trail exports — are restricted to Admin role only. No Manager, Banker, or Viewer can initiate a compliance data export. All exports are themselves logged in the audit trail.
Common exploit paths (/.env, /.git, WordPress probes) are blocked at the middleware level. The SPA catch-all route does not serve sensitive files. Rate limiting on all auth endpoints limits automated credential stuffing.
Underwriting checklist template management endpoints — create, update, delete — are secured with requireAdmin() middleware. Bankers and managers can use templates but cannot modify the template library.
BankerPipeline undergoes structured security sweeps rather than point-in-time audits. All findings from each sweep are tracked to resolution before the next sweep begins. The findings log below reflects the current verified state.
All critical, high, and medium findings from prior sweeps have been patched and independently verified. No open security findings as of the last review cycle.
Key security controls for your compliance team's evaluation.
| Control Area | Technology / Approach | Status |
|---|---|---|
| SSO / SAML 2.0 & OIDC | SAML 2.0 SP/IdP-initiated, OIDC authorization code flow — Okta, Azure AD, Google Workspace, OneLogin | ✓ Active |
| Two-Factor Authentication | TOTP RFC 6238 (Google Authenticator, Authy, 1Password), 8 backup codes, 30-day device remember, MFA setup + verify independently rate-limited | ✓ Active |
| JWT Algorithm Hardening | HS256-only allowlist — algorithm confusion (alg: none, RS256-to-HS256) vector closed | ✓ Active |
| Role Middleware (Admin/Manager) | requireAdmin() / requireAdminOrManager() — explicit allowlists, role-absent tokens fail closed, default role: viewer | ✓ Active |
| Brute Force Protection | Account lockout after 5 failed attempts, 15-min cooldown, progressive delay, no account enumeration | ✓ Active |
| Password Policy | Min 8 chars, upper/lower/digit/special, real-time strength indicator, password history, configurable expiry | ✓ Active |
| Session Management | HMAC-SHA256 JWT, token rotation on sensitive actions, bulk session invalidation, 8h/30d expiry | ✓ Active |
| PII Field-Level Encryption | AES-256-GCM — customers, guarantors (SSN/EIN, address, net worth), participation partners, referral contacts, HMDA demographic fields | ✓ Active |
| Password Storage | scrypt with per-password unique salts, Node.js built-in crypto — no plaintext, no shared salt | ✓ Active |
| XSS Prevention | HTML escaping on letter templates (stored), demo emails, SAML error handler (reflected); CSP with no unsafe-inline; nonce-based CSP | ✓ Active |
| Data Encryption at Rest | Neon PostgreSQL (AES-256), Cloudflare R2 (server-side encryption) | ✓ Active |
| Data Encryption in Transit | TLS 1.2+, HSTS (1-year), HTTPS-only (301 redirect) | ✓ Active |
| Role-Based Access Control | Admin / Manager / Banker / Viewer — feature-level permissions, server-side enforcement, explicit allowlists in middleware | ✓ Active |
| Multi-Tenant Isolation | org_id enforced on every read and write; branch INSERT org_id enforced; document sensitivity scoped; IDOR guards on activity creation | ✓ Active |
| CORS Lockdown | Wildcard removed — explicit allowlist: bankerpipeline.com, bankerpipeline.polsia.app | ✓ Active |
| Content Security Policy | CSP hardened — unsafe-inline removed from script-src; nonce-based CSP for remaining inline scripts | ✓ Active |
| File Upload Validation | MIME magic byte validation (not extension-only), file type allowlist, path traversal protection, 20 MB limit, signed upload tokens | ✓ Active |
| Error Response Sanitization | 82+ catch blocks sanitized — no stack traces, schema details, or file paths returned to clients | ✓ Active |
| Rate Limiting | 5 attempts / 15 min per IP on auth endpoints; MFA setup and verify independently rate-limited | ✓ Active |
| Security Headers | HSTS, CSP (no unsafe-inline), X-Frame-Options (DENY), X-Content-Type-Options, X-XSS-Protection, Referrer-Policy, Permissions-Policy | ✓ Active |
| Unified Audit Log | Append-only, 6-year retention, branch-scoped filter, 5 examiner quick-views, CSV export with chain-of-custody logging | ✓ Active |
| Exam Prep Dashboard | Direct links to all examiner views — Admin Actions (90d), Permission Changes, Failed Logins, Deletions, Data Exports | ✓ Active |
| Concentration Limit Monitoring | CRE/C&D ratios, single-borrower exposure — real-time gauges, breach alerts, configurable against bank capital | ✓ Active |
| Hosting Compliance | Render (SOC 2 Type II), Neon PostgreSQL, Cloudflare R2 | ✓ Active |
| GLBA Safeguards Alignment | Encryption, access controls, audit trail, HTTPS, PII protection, password policy, least-privilege defaults | ✓ Aligned |
| HMDA Demographic Data Encryption | AES-256-GCM encryption for race, ethnicity, sex fields — never plaintext at rest | ✓ Active |
| Borrower Portal Isolation | Horizontal + vertical isolation — borrower tokens rejected on all CRM endpoints; construction draws and closing worksheet scoped to own loan | ✓ Active |
| Borrower Portal Session Expiry | 24-hour expiry for borrower sessions (vs. 30-day for CRM staff) | ✓ Active |
| PII-Free Logs | PII excluded from server logs and error responses — only opaque identifiers logged | ✓ Active |
| Compliance Export Controls | HMDA LAR, CRA, and audit trail exports restricted to Admin role only; exports are chain-of-custody logged | ✓ Active |
| HMDA / CRA Access Controls | HMDA LAR and CRA data access restricted to authorized roles, all access logged | ✓ Active |
| Security Verification | 4 independent sweeps completed; 71/71 test cases passing; all prior audit findings (C-01, C-01b, C-02, H-08, M-01–M-06) resolved | ✓ Verified |