Verified identity
Firebase Authentication establishes user identity, while protected server routes verify Firebase tokens rather than trusting browser state. Passkeys and step-up authentication support sensitive access paths.
Security
OwnCents documents identity, authorization, workflow, and evidence controls at the boundaries where financial operations need them. This page describes application design without presenting source documentation as proof of deployment or certification.
Control model
Identity to evidence
Authenticate, resolve trusted scope, authorize, validate, execute through controlled services, and return sanitized results.
View security and complianceImplemented control design
Controls work together. Authentication alone does not grant workspace authority, and a workflow status alone does not prove an accounting result.
Firebase Authentication establishes user identity, while protected server routes verify Firebase tokens rather than trusting browser state. Passkeys and step-up authentication support sensitive access paths.
The workspace is the collaboration and tenant boundary. Legal Entities provide a separate accounting and reporting boundary, with server-side scope checks applied before protected data is read or changed.
Workspace membership, roles, granular permissions, and Legal Entity restrictions are evaluated on the server. Client-supplied roles, workspace IDs, provider IDs, and ownership claims are not treated as authority.
Production traffic is designed for encrypted HTTPS transport. Provider credentials stay server-side, sensitive stored provider tokens use encrypted handling where implemented, and secrets are excluded from public client configuration.
Enterprise SSO capability uses Firebase Identity Platform with verified domain relationships, provider checks, enforcement rules, and explicit recovery boundaries. Availability depends on plan and configured identity infrastructure.
Supported sensitive actions produce scoped audit records with safe actor and event context. Logs and public responses are designed to omit credentials, raw tokens, and unnecessary financial detail.
Higher-risk accounting flows use explicit states, role gates, optimistic versions, and maker-checker separation. AI can assist and explain, but it cannot approve, post, close periods, alter ownership, or move money.
Posted journals create Legal Entity-scoped immutable ledger evidence. Corrections use additive reversals instead of editing posted history, and reporting validates the supporting journal, ledger, and source evidence where required.
Provider and data protection
The Plaid webhook workflow verifies provider signatures before processing. Bounded raw-body handling, deduplication, and durable processing states reduce replay and duplicate-processing risk.
Sensitive business data is accessed through authenticated server APIs rather than open browser rules. Responses are scoped and sanitized, while provider tokens, internal claims, storage paths, and secrets stay out of client payloads.
Provider access is purpose-limited and credentials remain server-side. See the Privacy Policy for current handling, retention, disconnection, and deletion limitations.
Read the Privacy PolicyCompliance status
formal statuses are published only after verified approval
No compliance badge is currently approved for publication. OwnCents does not claim GDPR certification or any other unverified certification.