Personal Finance App Development

Consumer finance is one of the few product categories where engineering quality directly determines whether users trust a company with their most sensitive data. Scrums.com builds dedicated engineering teams for FinTech companies, neobanks, and financial services platforms that are developing personal finance applications: budgeting tools, wealth management apps, open banking aggregators, and financial planning platforms that require bank-grade security architecture, regulatory compliance, and the scale to handle millions of daily transaction records.

Financial Data Aggregation and Account Connectivity

The first engineering challenge in any personal finance platform is reading financial data reliably. Account connectivity follows three architectures depending on market and regulatory context.

Open banking APIs (PSD2 in Europe, CDR in Australia, Plaid/MX/Finicity in the US) are the lowest-friction path when available. The platform acts as an Account Information Service Provider (AISP): the user completes an OAuth-based consent flow, and the platform receives access tokens scoped to read account balances and transaction history. Token refresh, consent expiry, and re-authorisation prompts are managed by a bank_connection state machine that detects stale tokens and queues re-consent notifications via push before the connection silently breaks.

Screen scraping via credential vault remains necessary for institutions that have not implemented open banking APIs. Credentials are encrypted at rest using AES-256 with envelope encryption (AWS KMS or HashiCorp Vault), never stored in application databases. Scraping sessions run in isolated containers with automatic teardown.

Manual CSV import handles edge cases: pension platforms, international accounts, legacy bank exports. An import pipeline normalises date formats, currency codes (ISO 4217), and transaction descriptions into the canonical schema before appending to the transactions ledger.

All three ingestion paths converge on the same append-only transactions table. A deduplication key (account_id + institution_transaction_id, or a hash of date/amount/description for scraped data) prevents re-ingestion from creating duplicates during polling cycles. Balance snapshots are stored separately at point-in-time, not derived from transaction sums, because institution rounding and pending transaction states make running-sum balances unreliable.

Transaction Categorisation and Budget Engine

Categorisation is the core value-add of a personal finance platform. A three-tier classification approach provides both accuracy and explainability.

The first tier is a merchant registry: a lookup table mapping normalised merchant names (after stripping branch codes and transaction reference noise) to category, sub-category, and merchant metadata. This covers 70 to 80% of transactions for a typical user without any ML inference. The normalisation pipeline uses regex stripping of common bank description patterns (POS, REF, TXN IDs) followed by fuzzy matching against the merchant registry.

The second tier is an ML classifier (fine-tuned on labelled transaction datasets, deployed via ONNX Runtime for inference latency below 50ms) that handles merchant-registry misses. The classifier outputs a category prediction with a confidence score. Predictions below 0.8 confidence are queued for human review in a labelling interface that feeds back into the training dataset.

The third tier is user correction: when a user re-categorises a transaction, the correction is written to a user_overrides table and replicated to the merchant registry as a low-weight training signal. User corrections are immediately applied to all future transactions from the same normalised merchant for that user.

Budget tracking uses an append-only budget_events ledger. A budget is not a mutable record; it is a sequence of events: budget_created, budget_amended, budget_rollover. Rollover policy (carry forward, reset, or cap rollover) is configuration per budget category. Spend-against-budget is computed as a projection query at read time, not a pre-aggregated field, ensuring that re-categorisations retroactively affect budget utilisation without needing to update budget records.

Personal finance platforms like these are built and scaled through dedicated teams via our mobile app development service.

Investment Portfolio and Wealth Management Infrastructure

For platforms that extend beyond spending management into investment tracking and wealth management, the data model expands around a holdings ledger.

Holdings are tracked as an append-only event log: buy, sell, dividend, corporate_action (stock split, merger), fee. The current portfolio position at any point in time is computed as a projection over this ledger. This means historical performance calculations are always accurate to the original cost basis, regardless of later corporate actions: a critical requirement for tax reporting.

Market data ingestion pulls daily close prices (or intraday for premium tiers) from a financial data vendor (Polygon.io, Alpha Vantage, or a direct exchange feed). Prices are stored with the vendor source and timestamp in a price_history table rather than overwritten, so that back-calculated returns are auditable. Currency conversion uses the exchange rate at the trade date for cost basis, and the rate at the valuation date for current value: two separate rate lookups, not a single latest rate.

For platforms providing investment recommendations or discretionary management (robo-advisor functionality), the regulatory boundary is significant. Engineering can support a compliant robo-advisor by implementing a rules engine that maps user-provided risk profiles and investment horizons to permitted portfolio allocations, with every recommendation logged with the rules version that generated it and the user inputs that triggered it.

Goal-based planning tracks progress toward named financial goals (emergency fund, house deposit, retirement) by associating allocations with goal IDs and computing trajectory projections using Monte Carlo simulations against the user's risk profile parameters. Projections are cached as read-model snapshots and refreshed nightly; running live Monte Carlo per request does not scale to millions of users.

Security Architecture and Regulatory Compliance

Personal finance platforms are high-value targets. Security architecture must be threat-modelled as if breach is inevitable; the question is containment.

PCI DSS applies if the platform stores, processes, or transmits cardholder data. The practical approach is to never touch raw card data: use a PCI-compliant vault (Stripe, Braintree) for any payment initiation, and ensure that card numbers never transit the platform's own servers. PCI scope is dramatically reduced when the platform only reads transaction metadata via open banking APIs rather than initiating card transactions itself.

Encryption at rest uses AES-256 with per-row encryption keys for PII fields (name, email, date_of_birth, national_id). Envelope encryption via a KMS means that compromising the application database does not expose plaintext PII. Field-level encryption means GDPR erasure can be implemented by destroying the row's DEK (Data Encryption Key) rather than overwriting every record, which is significantly faster for large ledgers.

Access control follows RBAC with an audit log on every privileged action. Customer support roles have read-only access to anonymised account summaries, not plaintext financial data. Privileged access for on-call engineers requires time-limited JIT grants (AWS IAM roles with session tokens, not permanent credentials) with every access logged and reviewed weekly.

PSD2 Strong Customer Authentication (SCA) requires that payment initiation be authenticated with at least two factors from: something the user knows (PIN), something the user has (device), something the user is (biometric). The SCA challenge flow is implemented as a separate microservice so it can be updated when regulatory technical standards change without redeploying the core banking integration layer.

GDPR/CCPA data minimisation is enforced at collection time: the ingestion pipeline rejects fields not declared in the data map. Transaction description fields that contain free-text from merchants are considered PII under GDPR (they may contain names or account references) and are encrypted accordingly.

Building a FinTech platform that handles user financial data responsibly? Start a conversation with Scrums.com or explore our FinTech engineering capabilities.