Important scope statement. Ask BankCFO is currently a self-service beta, not a completed bank-vendor certification package. Core analysis is designed around public regulatory data. Controls marked Current are implemented in the application code. Controls marked Verify / document depend partly on hosting configuration and should be evidenced during vendor review. Controls marked Pre-commercial remain required before paid production use or broader handling of customer-confidential bank information.
Primary analytical source
Public FDIC / FFIEC dataCore peer and Call Report analytics are based on public regulatory information.Authentication
Server-side sessionsScrypt password hashes, random session tokens and hashed token storage.Sensitive local data
Browser-local by designSelected internal deposit/product and report-content records are excluded from cloud-safe synchronization.Assurance status
Beta / hardeningFormal penetration testing, SOC 2 evaluation and the full vendor evidence package remain roadmap work.Data architecture & handling
The application intentionally distinguishes public regulatory data, cloud-safe workspace configuration and records designated local-sensitive.
1 · Public sources
FDIC / FFIECBankFind APIs and user-imported public FFIEC single-period Call Report ZIPs.2 · Application
Workspace-scoped processingAuthenticated server routes, analytical calculations, reconciliation and selected raw MDRM retention.3 · Storage boundary
PostgreSQL + browser localCloud-safe records are workspace-scoped. Explicit local-sensitive sets remain in the browser by design.4 · Optional AI
Sanitized contextHosted AI is workspace-controlled and receives the application context explicitly sent by the browser, not arbitrary local files.What the server currently stores
- User account identifiers, registration details, trial dates and password hashes.
- Hashed active session tokens and expiration timestamps.
- Workspace membership and role.
- Cloud-safe workspace records such as peer groups, report templates, snapshots, alert rules and opportunity scenarios.
- Imported public FFIEC driver MDRM values needed by the application, scoped by workspace and quarter.
- Audit events and hosted-AI usage metadata.
- Support and feedback submissions sent through the Contact page.
What is intentionally local-sensitive
- Internal deposit/product rows.
- Deposit-product scenario detail.
- Management-report commentary.
- Rendered report archives.
These record types are explicitly excluded from the cloud-safe synchronization bundle in the current design. Future multi-user support should re-evaluate whether any local-only data needs an encrypted, access-controlled server option.
Application control inventory
Status reflects what can be supported by the current v24.2 application code. Hosting controls still require separate provider evidence.
| Control area | Status | Current implementation / evidence | Paid-production follow-up |
|---|---|---|---|
| Password storage | Current | Passwords are salted and hashed using Node's scrypt implementation. Plaintext passwords are not stored by the application. | Document password policy, reset process and administrative recovery workflow. |
| Session security | Current | Random 32-byte session tokens; only SHA-256 token hashes are persisted. Cookies are HttpOnly, SameSite=Lax and marked Secure in production. | Add explicit idle-session policy and review session-duration defaults for bank customers. |
| Login rate limiting | Current | Login and self-registration are rate limited. Support submissions and hosted-AI calls also have separate rate limits. | Add broader abuse monitoring and documented response thresholds. |
| Authorization / tenancy | Current | Server records are filtered by authenticated workspace ID. Workspace roles exist and selected owner-only operations are enforced. | Complete a formal authorization review and automated cross-tenant negative tests before multi-customer launch. |
| Audit logging | Current | Audit events are written for login activity, cloud-safe synchronization, AI activity/settings and FFIEC import/delete actions. | Define retention, centralized alerting, admin review and export requirements. |
| Temporary FFIEC uploads | Current | Public Call Report ZIPs are parsed from a temporary upload and the temporary file is deleted after processing; only retained MDRM fields are stored. | Document temp-storage location and provider-level disk lifecycle. |
| HTTP security headers | Partial | Helmet is enabled. Content Security Policy is intentionally disabled in the beta because the current app relies heavily on inline script/style. | Refactor/test the frontend and enable a restrictive CSP before broad launch. |
| Encryption in transit | Verify / document | The application marks session cookies Secure in production and is intended to operate behind HTTPS. | Retain production TLS/provider evidence and document supported protocol/cipher posture. |
| Encryption at rest | Verify / document | This is primarily a database/hosting-provider control rather than an application-code claim. | Confirm and retain provider evidence for database, backup and volume encryption. |
| MFA | Not yet | No MFA flow is implemented in the current beta authentication layer. | Add MFA before paid production rollout, with recovery and administrative reset controls. |
| Vulnerability management | Pre-commercial | Dependencies are declared and can be updated, but a formal scanning/remediation program is not yet evidenced here. | Implement dependency scanning, vulnerability triage SLAs and tracked remediation. |
| Penetration testing | Pre-commercial | No independent penetration-test claim is made. | Complete an independent test after launch architecture stabilizes; retain an executive summary and remediation evidence. |
| SOC 2 | Roadmap decision | Ask BankCFO is not represented as SOC 2 certified. | Evaluate timing and scope based on target-bank expectations after beta-customer feedback. |
Hosted AI boundary
AI functionality should be explainable during vendor review because banks may treat model-provider data flows differently from ordinary application processing.
Current design
- Hosted AI can be enabled or paused at the workspace level.
- Workspace request/cost caps are supported.
- The browser sends an explicitly constructed bank-intelligence context plus the user's chat text.
- AI usage and errors are audit logged.
- Core numerical analytics and lineage remain available without hosted AI.
Evidence required before broad launch
- Publish the AI/model provider as a subprocessor where applicable.
- Document provider retention and training/data-use terms applicable to the production account.
- Document categories of context that can be sent and local-sensitive categories that are excluded.
- Provide a customer-facing AI setting and clear disclosure of the data path.
Incident response, resilience & operations
These controls require both application procedures and production-hosting evidence. The beta is being used to define the operating standard before paid production release.
Required operating procedures
- Security incident classification, escalation, containment and customer-notification workflow.
- Backup monitoring and documented restore testing.
- Business continuity plan with defined RTO and RPO.
- Change-management and production-deployment approval trail.
- Security log review and alert escalation.
- Customer offboarding, data export and deletion procedure.
Provider evidence to retain
- Hosting architecture and regions.
- Database backup, recovery and encryption controls.
- Availability/status history.
- Subprocessor/service-provider list.
- Applicable provider SOC / ISO reports or bridge letters.
- Cyber insurance evidence once commercialized.
Not yet published as guarantees: RTO/RPO, uptime SLA, breach-notification timing, retention periods and deletion SLAs. These should be set only after the production hosting and operating model are finalized.
Bank vendor-management evidence roadmap
The goal is to give a bank's finance, IT, information-security and third-party-risk teams a coherent package instead of making them reconstruct the product's control environment from marketing claims.
Architecture & data-flow diagramApplication, database, FDIC/FFIEC sources, optional AI provider, browser-local boundary and authentication flow.
Security control summaryAuthentication, authorization, logging, encryption, vulnerability management, SDLC and change management.
Incident-response summaryRoles, severity model, escalation, containment, investigation and customer communication.
BCP / disaster recoveryBackup architecture, restore tests, RTO/RPO and dependency continuity.
Privacy & retentionData categories, purposes, retention, deletion, customer rights and AI handling.
Subprocessor registerHosting, database, monitoring, email/auth support, AI and payment providers actually used in production.
Independent assurancePenetration-test executive summary and remediation; SOC 2 or other assurance if/when justified by customer demand.
Legal & insuranceTerms, privacy policy, data-processing terms, cyber coverage and appropriate contractual commitments.
Security gates before audience expansion
Paid production use and broader bank adoption should wait until the most important identity, web-security, operational and evidence gaps are closed.
Recommended paid-production gate: complete MFA; enable/test CSP; perform authorization and tenancy tests; establish dependency/vulnerability scanning; complete restore testing and formal BCP/IR documentation; publish privacy/retention/subprocessor terms; complete an independent penetration test; and review the final architecture with the first beta banks' vendor-management questionnaires.
Questions from a bank's vendor-management team
During the beta, security and due-diligence questions are treated as product requirements. A dedicated contact form is live today; the downloadable evidence packet and document-request workflow remain part of the commercialization roadmap.
Return to product overview · Contact / due diligence · Sign in