Every security control on this page is implemented and verifiable in production. We list only what is built — not what is planned. Community banks deserve transparency, not a marketing checklist.
Full SSO integration for enterprise deployments, hardware-compatible MFA, and layered session security built on Node.js cryptographic primitives — no third-party auth dependencies.
Per-organization SSO configuration supporting all major enterprise identity providers. Administrators choose between optional SSO and enforced SSO — enforced mode blocks email/password login entirely, routing all authentication through your identity provider.
Time-based one-time passwords (RFC 6238) compatible with any standard authenticator app — Google Authenticator, Authy, 1Password, and hardware tokens like YubiKey (OTP mode). Implemented with zero external authentication libraries.
OAuth 2.0 social login via Google and Microsoft for organizations that prefer consumer-identity SSO over enterprise SAML/OIDC. Each provider is configured per-organization. User accounts are provisioned automatically on first login with email matching for existing accounts.
After a successful MFA verification, users can opt to trust their current device for 30 days. Trusted devices bypass the MFA challenge without weakening session security — trust tokens are cryptographically signed and validated server-side on every use.
Session tokens are signed JWTs (HMAC-SHA256) delivered as httpOnly, Secure, SameSite=Lax cookies — never exposed to JavaScript. All tokens are tracked in the database for revocation. A deactivated user's session is terminated at the next request.
Failed login attempts trigger progressive lockout, preventing brute-force attacks against email/password accounts. The same lockout policy applies to MFA attempts — both layers are protected with matched thresholds. Security events are logged to the audit trail.
Users can reset their password via a time-limited, single-use token sent to their verified email address. Tokens are SHA-256 hashed before storage — even if the database were compromised, reset tokens could not be replayed. The endpoint is rate-limited to prevent abuse.
Sensitive credentials are encrypted at the application layer before reaching the database. All communication is TLS-only. Password hashing uses scrypt — a memory-hard algorithm resistant to GPU-accelerated brute force.
Sensitive credentials — TOTP secrets, EIN/tax ID numbers, and other regulated data — are encrypted with AES-256-GCM before being written to the database. Even with direct database access, these values cannot be read without the application encryption key.
All traffic is TLS-encrypted. HTTP connections are redirected to HTTPS in production. HSTS headers instruct browsers to enforce HTTPS for all future visits — including subdomains — for one year, with preload eligibility.
Passwords are hashed using scrypt, a memory-hard key derivation function. Each password uses a unique 16-byte random salt. All comparisons use crypto.timingSafeEqual() to prevent timing attacks.
Every database query uses parameterized statements with the Node.js pg driver. User-supplied input is never interpolated into SQL strings, eliminating SQL injection as an attack surface.
Every material action in BankerMarketer is recorded in an append-only audit log. Records are never modified or deleted. Your compliance examiner can see exactly who approved what, when, and why.
Every administrative and compliance action writes an event record. Records are insert-only — no updates, no deletes. The log cannot be retroactively altered by any user, including administrators.
Every sponsorship request is tagged with CRA categories at submission. Reports are exportable for examiner review. Budget tracking enforces annual and quarterly spend limits with automated alerts at 75% and 90% of threshold.
A daily automated audit runs 20+ security checks across every tenant at 2am UTC. Each check probes real-time system state — not configuration snapshots — across five categories: Authentication, Access, Data, Configuration, and Compliance. Results surface immediately in the owner dashboard.
Every tenant receives a letter-grade security scorecard (A through F) computed from the daily audit results. Scores are visible in the owner console alongside per-tenant findings. Banks can export their scorecard as a compliance PDF for vendor review or examiner presentation.
Data Loss Prevention findings are tracked per tenant with severity classification, status workflow, and audit-logged dismissals. Access review certifications allow administrators to certify the appropriateness of user access on a scheduled basis — supporting periodic access control attestation required by bank regulators.
Census tract geocoding, LMI income designation, and Fair Lending analysis handle sensitive demographic information. Every step — from data sourcing to classification — is governed by controls designed for regulatory scrutiny.
Census tract and income data is sourced exclusively from the US Census Bureau API (geocoding.geo.census.gov) and FFIEC Census data. No third-party data brokers. All API requests use HTTPS. No API key required — public endpoints only.
Beneficiary demographic fields (population served, count estimate, geographic area) are collected at the request level and stored with full org scoping. Demographic fields are stored in the same org-scoped database as financial data — not separated into a different system.
Every CRA classification change — activity type assignment, reviewer override, eligibility determination — is written to the immutable audit log. The log records who changed what, when, and why, supporting examiner scrutiny of your CRA program decisions.
Volunteer hours and headcount logged on CRA community service calendar events are timestamped at event creation and last modification. The audit log captures all changes to volunteer data — supporting the Service Test narrative with verifiable numbers.
Data isolation is enforced at the database query layer — not just the UI. Every query is scoped to the requesting organization's ID. Server-side auth guards protect all routes. Cross-tenant data leakage has been verified absent through security testing.
Every tenant data table carries an org_id foreign key defined as NOT NULL at the schema level. All queries enforce organization scoping — no data leaks between tenants regardless of IDs, filters, or sort parameters supplied by the client. Cross-tenant isolation has been verified by security testing.
Four default roles — Admin, Approver, Manager, User — with permission sets stored as structured JSON per organization. Users can hold multiple roles simultaneously. Role assignments are logged in the audit trail with the assigning administrator's identity.
The platform owner console — which provides cross-tenant visibility and administrative controls — is protected by a dedicated requireOwner middleware layer. Owner-only endpoints are completely inaccessible to regular tenant users, regardless of role or privileges within their organization.
Response headers are set on every request to restrict what browsers permit. These controls prevent clickjacking, MIME-type confusion, cross-origin data leakage, and unauthorized feature access.
A strict CSP restricts script and resource loading to trusted origins only. No unsafe-inline — all scripts are loaded from external files. Inline frames and object embeds are blocked entirely. Insecure requests are upgraded automatically.
A defense-in-depth set of HTTP response headers locks down browser behavior across all response types — blocking framing, MIME sniffing, referrer leakage, and browser feature access. Server-identifying headers are removed to limit reconnaissance.
Rate limits are enforced globally at the application layer using IP-based tracking. Counters are persisted in the database — rate limit windows survive server restarts and deploys, preventing window-reset attacks. Authentication endpoints (login, MFA, registration) have tighter limits than general API calls. Public-facing forms have separate limits to prevent abuse. All limits are server-side — not bypassable via client manipulation.
Uploaded files are validated against their actual binary content (magic bytes), not just the file extension or declared MIME type. File downloads are served through a secure proxy that forces browser download behavior and prevents content sniffing — eliminating serving of user-uploaded content as executable HTML or scripts.
A dedicated owner console provides real-time security visibility across all tenants — severity trends, scorecard grades, active findings, and configurable alerts. Built for security teams managing multiple bank deployments.
The owner portal surfaces live counts of Critical, High, Medium, and Low findings across all tenants, with 30-day and 90-day trend charts. Security posture changes are visible immediately after each daily audit run.
A full-featured findings explorer lets operators browse, filter by severity and category, and action individual findings with a structured dismissal workflow. Every dismissal is captured in the audit trail with actor, timestamp, and reason.
Operators configure alerts for specific security events — new Critical findings, score drops below a threshold, and tenant-level security regressions. Alerts are delivered via email and logged as notification events. Per-event muting is available for expected/accepted findings.
Social posts, inbound messages, and engagement data are governed by the same compliance controls as your CRA program. Every interaction is archived, timestamped, and exportable for bank examiner review — no competitor in the community bank space offers this level of social media compliance.
All published posts, comments, and direct messages are captured in an append-only archive the moment they go live. Every record carries a tamper-proof timestamp, SHA-256 integrity hash, and actor identity — the archive cannot be retroactively edited or deleted by any user, including administrators.
Compliance officers and examiners need to pull records without a developer. Four report types are available in PDF and CSV — content review, response audit, archival certificate, and activity summary — each formatted for direct submission to bank examiners during CRA and compliance audits.
Every outbound post must pass through a compliance review gate before publishing. Drafts, edits, approvals, and rejections are all tracked in the audit trail. No post reaches a social account without an approver's record — and no rejection is unlogged.
Every inbound social message is logged at receipt — customer inquiries, mentions, and DMs. Messages carry SLA timers from arrival, assignment history, and canned response governance. No customer interaction goes unlogged, and no response is sent outside an approved template library.
Engagement metrics, follower changes, reach, and post performance are captured historically — not as point-in-time snapshots. Every metric record carries a timestamp and source attribution, enabling board reports and examiner reviews that show trend, not just current state.
Inactive sessions are terminated automatically. The idle timeout is configurable per-organization, enforced server-side regardless of SSO or device trust settings, and includes client-side countdown warnings across all open tabs.
Organization administrators select their idle timeout threshold from six options: 5, 10, 15, 30, 60 minutes, or completely disabled. The setting applies to every session in that organization and is enforced on the server — it cannot be bypassed from the client.
Activity detection runs client-side across all open tabs — activity in any tab resets the timer for all tabs. Background polling requests are explicitly excluded from activity detection, so API health checks won't artificially extend sessions. Server-side enforcement provides the authoritative session termination layer.
Before a session expires due to inactivity, users see a countdown warning modal. The modal provides a live countdown and a one-click "Stay Signed In" button, giving users a clear window to extend their session without losing work. All idle timeout events are logged to the audit trail.
Every outbound webhook is cryptographically signed, rate-limited, and timeout-protected. Delivery attempts are retried with exponential backoff and all configuration changes are captured in the audit trail.
All outbound webhook payloads are signed with HMAC-SHA256 using a per-webhook secret. Receivers verify the signature on every request — any payload that fails verification is rejected. Secrets are auto-generated at 256 bits, shown once on creation, then stored as a hash.
Webhook destination URLs are validated before delivery to block Server-Side Request Forgery attacks — internal and private IP ranges (10.x, 172.16.x, 192.168.x, localhost) are rejected. Organizations are capped at 10 webhooks each and 1,000 deliveries per hour across all webhooks.
Webhook delivery attempts timeout after 10 seconds per attempt. Failed deliveries retry with exponential backoff up to a fixed maximum — no infinite retry loops. All webhook CRUD operations and delivery outcomes are recorded in the audit trail.
Data exports are restricted to administrators, rate-limited per organization, and contain only the requesting organization's data. No cross-tenant data can appear in any export.
Data export endpoints are gated behind role-based access control — only users with the Admin role can trigger exports. All export operations are written to the audit trail with the actor's identity, timestamp, and the scope of data exported.
Export queries are always scoped to the requesting user's organization ID — enforced at the application layer with org_id filtering on every export query. No endpoint can return data belonging to a different organization. Export files contain only the requesting org's records.
Every control below is confirmed in production code — not roadmap items.
We're happy to complete your vendor security questionnaire, walk through the architecture with your IT team, or provide documentation for your examiner. Contact us for SOC 2 details or a dedicated security review call.