Security at Nora

Your bank credentials never reach Nora

Nora connects supported institutions through Plaid. You sign in through Plaid or your institution’s authorization process. Your bank username and password are never entered into, sent to or stored by Nora. Plaid gives Nora an access token for the information you approved. This token is not your bank password.

Nora cannot move your money

Nora's current financial-account access is read-only. It can retrieve and analyze supported balances and transactions, but it cannot make payments, initiate transfers, withdraw money, or trade securities. The finance tools used by Nora Chat and Boards are read-only too.

Tokens and credentials stay on the server

Nora encrypts Plaid access tokens before storing them. Provider credentials, encryption keys, database credentials and AI-provider credentials stay on the server and are not exposed to the browser. Provider connection records are stored separately from the standardized account and transaction records used in Nora.

Nora checks who can access your data

For protected requests, Nora checks your signed-in session to establish your identity. It does not trust a user ID sent by the browser. These ownership checks cover accounts, transactions, related merchant and category activity, provider connections, Nora Chat threads and Boards.

AI has limited access

Nora currently uses Google Gemini for Nora Chat, requested explanations, Board creation and editing, and merchant enrichment. The model does not have unrestricted database access. Nora's authenticated finance tools select permitted data and perform calculations before relevant results are sent to the model.

Depending on the feature, the limited context sent to Gemini can include messages, relevant finance-tool results, verified explanation facts, Board instructions and content, or merchant names and transaction descriptions. Bank passwords, Plaid access tokens, and encryption keys are not included in that financial context.

Nora checks AI output, but errors are possible

Before Nora stores or displays an AI-generated Board, it must pass checks for allowed components, tools, operations and financial scope. Requested explanations use financial operations controlled by the server. These checks reduce risk. AI explanations and classifications can still be incomplete or wrong.

What operational logs contain

Nora records limited information needed to understand reliability, AI usage, and performance, such as model or feature names, token counts, timing, finance-tool names, status, and errors. Dedicated AI-usage and chat-performance records are designed not to contain prompts, responses, tool arguments or results, transaction descriptions, provider credentials, or account identifiers. Saved Nora Chat conversations are separate product content.

The server-side Better Auth Infrastructure Dash plugin separately sends authentication lifecycle and audit events that can include user, email, session, login-method, user-agent, IP, and approximate location information. Nora does not enable Sentinel browser fingerprinting, proof-of-work, or request blocking.

Optional PostHog analytics and session replay require separate affirmative choices and use a rotating anonymous browser identifier. Events exclude financial values, prompts, content, and account or provider identifiers. Replay masks text and inputs and blocks financial pages, Chat, Boards, settings, authentication, Plaid, search, and exports. Network bodies and headers, console logs, clipboard contents, canvas, and provider frames are excluded. Nora can disable browser PostHog initialization in production.

Email-and-password accounts must verify their address before financial features are available. Verification and recovery links expire after one hour, recovery links are single-use, successful password resets revoke existing sessions, and authentication endpoints are throttled. Authenticated password changes require the current password, revoke other sessions, and trigger a security notice. Resend webhook signatures are verified; Nora stores hashed-recipient delivery metadata for 90 days and suppresses addresses after bounce or complaint events.

Disconnecting and deleting are different

Disconnecting an institution stops Nora's normal synchronization path and asks Plaid to remove the connection. If Plaid removal is pending, Nora may temporarily retain the encrypted token so removal can be retried. After provider removal completes, Nora offers a separate action that soft-deletes data imported through that connection from normal product use.

Soft deletion does not guarantee immediate physical erasure from every storage system or backup. Nora's account-wide deletion flow, permanent purge schedule, and backup-retention periods are not yet implemented in the reviewed codebase.

Access by administrators and providers

Nora is currently operated by Benjamin Ollomo. Access is limited to authorized administrative and provider tools. Better Auth Infrastructure provides provider-hosted authentication audit and user or session administration capabilities. Nora also relies on Plaid, Google, MongoDB, Vercel, and Brandfetch to provide specific parts of the service. A provider's certification does not mean Nora holds that certification.

No system is completely secure

No internet-connected service can guarantee complete security. Nora does not claim SOC 2, ISO 27001, ISO 27701, an independent penetration test or similar assurance it has not completed. Security controls and operating procedures will change as the product develops.

Reporting a vulnerability

Report security concerns to support@nora-fi.com. Include enough detail to understand and reproduce the issue, do not access or retain another person's information, and allow a reasonable opportunity to investigate before public disclosure.

Monthly budget controls

Budget endpoints enforce session ownership, same-currency account scope, category ownership, revision checks, and unique monthly records. Browser responses are private and not cached. Calculations use a consistent database snapshot and fail unavailable if their bounded processing limit is exceeded. Budget screens are excluded from replay; Admin monitoring exposes aggregate counts and integrity status without targets or transaction evidence. Budget alert evaluation and persistent deduplication share an owner-scoped atomic database snapshot; source imports record suppression independently of the event listener.

Usual budgets are versioned from an effective month, with explicit month-only exceptions. Earlier months retain their previous configuration. Editable suggestions use average eligible spending across the previous three calendar months; incomplete imports may lower them. They are not affordability recommendations, do not use AI, and are saved only when you choose. Ongoing versions and exceptions are included in your export.