Coinest Systems & Privacy Architecture

1. Introduction & Motivation

Modern personal finance management (PFM) platforms suffer from a fundamental architectural flaw: over-collection and persistent hoarding of raw financial documents. When a user uploads a 12-page bank statement or receipt, most cloud services store the raw document in permanent blob storage (e.g. AWS S3 or Google Cloud Storage) indefinitely.

This persistence exposes consumers to three catastrophic risk vectors:

1. Static Data Breach Risk: Stored bank PDFs contain permanent identity identifiers (full names, home physical addresses, account IBANs, employer details, and sensitive merchant transactions).
2. Model Poisoning & PII Ingestion: Modern LLM workflows often inadvertently log raw payload buffers into third-party training pipelines without cryptographic redaction.
3. Joint vs. Personal Scope Leakage: Joint household tools frequently force an all-or-nothing data sharing model, exposing private healthcare, legal, or personal expenses to other household members.

Coinest addresses these vulnerabilities through a stateless, zero-retention processing engine coupled with strict PostgreSQL Row-Level Security (RLS) and dual-scope isolation.

2. Threat Model & Security Assumptions

We evaluate Coinest against a formal threat model covering external network adversaries, malicious tenant actors, and cloud infrastructure sub-system compromise.

3. The Zero-Retention PII-Redaction Pipeline

The core of Coinest's statement ingestion engine operates entirely within stateless compute instances running in AWS Stockholm (eu-north-1).

3.1 Deterministic Pre-Inference PII Redaction

Prior to any categorization or LLM enrichment, statement and transaction text passes through a deterministic redaction filter matching international bank account numbers (IBANs conforming to ISO 13616), email addresses, telephone numbers, and labeled name/address fields on statement headers, replacing each match with a placeholder token (e.g. __REDACTED_IBAN_1__). The LLM provider only ever receives the redacted text; a local mapping — held only in the request's own memory, never persisted — restores the real values afterward so the actual financial detail lands exclusively in Coinest's own encrypted tenant database.

3.2 Regulated Bank-Connection Architecture

In addition to manual statement parsing, Coinest supports automatic account-information synchronization through regulated European open-banking providers. Bank authentication and consent happen between the user, their bank and the regulated provider. The resulting connection architecture operates under five strict guarantees:

• Strict Read-Only Access (AIS Only): Coinest uses account information supplied on a read-only basis. The product does not expose payment initiation and cannot initiate payments or move money from connected accounts.
• Field-Level Encrypted Credentials: Open Banking requisition IDs, access tokens, and account references are encrypted at the application layer (Fernet: AES-128-CBC with HMAC-SHA256 authentication) before ever being written to a database row, and decrypted only at the point of use.
• Zero Long-Term Token Stash: Third-party banking credentials never touch public endpoints or client cookies. All API handshakes execute server-to-server within our AWS Stockholm VPC.
• Licensed, Regulated Providers Only:Bank connections are established through regulated European open-banking providers. Coinest never receives or stores a user's online banking credentials; authentication, consent lifecycle and expiry are governed by the bank and regulated provider.
• Full-Erasure Coverage: Executing a GDPR data-erasure request (Section 8) permanently deletes all stored bank and broker connection credentials as part of the same cascade — no encrypted token outlives an account deletion.

4. Scope Isolation: Household vs. Personal

A joint household product has to answer two different isolation questions at once: which household does this record belong to (tenant isolation — no household can ever see another household's data), and, within a household, is this record shared with every member or privateto the one person who added it (member isolation — a partner should never see a spouse's therapy co-pay or a surprise gift purchase). Coinest enforces both with the same mechanism, at the database layer, rather than as an application-level convention.

Every record that can carry personal data — a bank account, a transaction, an invoice line item — has exactly two identity columns: a household_id (which household owns this row) and a nullable user_id (which individual member owns it). NULL means the row is shared with the whole household; a real member id means it is visible to that person alone. This is enforced by PostgreSQL Row-Level Security in FORCEmode, so the constraint holds even for Coinest's own application database role — a query that forgets to filter by owner does not accidentally see more, it structurally cannot.

This is verified continuously rather than trusted at design time: every code change is checked by an automated static-analysis pass that fails the build if a database query touching household or personal data is missing the correct isolation predicate, and by a live database check that confirms the isolation policies actually deployed match what the codebase declares. Both checks run before any change can be merged.

Security-sensitive mutations add a second, independent boundary: their SQL includes explicit household_id and personal-owner predicates and returns the identifiers that were actually changed. This defense-in-depth rule applies even where RLS already exists, limiting impact if a maintenance or production role is ever granted BYPASSRLS. Bulk tax-purpose tagging, for example, validates a bounded set of transaction identifiers, updates only records visible to the authenticated household member, and reports only the rows PostgreSQL actually accepted.

5. Longitudinal Event Modeling & Household Timeline

Traditional personal finance software treats financial transactions as independent, memoryless Markov chains. In contrast, real household finances undergo discrete life epoch transitions—such as welcoming a child, purchasing a home, undergoing a career pivot, or taking a sabbatical.

Coinest introduces Longitudinal Event Modeling:

• User-Declared Life Milestones: Rather than guessing through noisy unsupervised transaction clustering, users declare upcoming milestones in natural language (e.g., “We are expecting a baby in November and need a €4k setup fund”).
• NIBUD Safety Buffer Preservation: Feasibility is evaluated not by gross liquidity, but by free available capital above the household's NIBUD-mandated emergency cushion(Free Savings = Total Liquid − NIBUD Buffer).
• Dynamic Dutch Subsidy & Cashflow Impact: Structural burn adjustments (Δ Monthly Burn) model shifts in daycare expenditure, parental leave income reductions, and Dutch Kinderopvangtoeslag subsidy updates concurrently.
• Context-Aware Agent Memory: Active milestones are automatically provided to Mikka (the AI financial copilot), enabling longitudinal contextual reasoning rather than generic isolated answers.

6. Evaluation Status & Reproducibility

To maintain scientific integrity, this paper does not publish quantitative performance figures (such as benchmark dataset size, extraction accuracy, categorization match rates, or ingestion latency) that have not been validated through a reproducible, publicly documented evaluation. As of the publication date of this paper, Coinest has not completed such a benchmark of its parsing and categorization engine, and no performance numbers should be inferred from this document.

A reproducible evaluation across major Dutch and European statement formats (ING Bank, Rabobank, ABN AMRO, SNS Bank, Revolut, N26, and American Express) is planned. Dataset composition, methodology, and results will be published together once validated.

7. Known Limitations & Roadmap

To maintain scientific integrity and transparent engineering standards, we document current system boundaries:

• Heavily Degraded Physical Receipts: Thermal receipts with severe physical fading or wrinkled paper may require manual amount confirmation in the UI.
• Password-Protected PDF Statements: Encrypted PDF statements must have their password entered client-side to allow in-memory decryption before parsing.

8. GDPR Compliance & Data Portability Guarantee

Coinest implements the data-subject rights granted under Articles 15, 17, and 20 of the General Data Protection Regulation (EU GDPR):

• Right to be Forgotten (Art. 17): Executing DELETE /api/user/account permanently deletes the caller's data — transactions, categories, encrypted broker/bank credentials, and every other stored record — a real deletion, not a soft-delete flag. In a joint household, this correctly erases only the departing member's own personal records and shared-account membership, leaving other members' data intact; erasing the entire household's shared data is a separate, explicitly consented action.
• Data Portability (Art. 20): Users can export their complete financial ledger at any time via GET /api/user/export-data in standardized JSON/CSV formats without vendor lock-in.