The standard PFM dashboard shows a line chart of account balance over time. The x-axis is weeks or months. The y-axis is the account total. The line goes up when income arrives and down when spending happens. It looks like financial data. It communicates almost nothing useful about spending behavior.
Balance history is a snapshot view. It tells you where you ended up, not how you got there. A balance dropping from $3,200 to $2,400 in a week could mean a restaurant bill, a car repair, a medication, a planned purchase, or a recurring subscription you forgot about. The balance chart cannot tell you which, and so the user cannot learn anything from it beyond "I have less money than I did."
The data structure that actually supports spending insight is cashflow signals: categorized, directional cash events tagged by merchant, time, and recurrence. This post is about why that distinction matters for product decisions, and what it takes to build a PFM layer that operates on cashflow signals rather than balance snapshots.
What Balance Snapshots Miss
Consider a user with the following transaction week:
- Monday: $68 grocery run (planned, weekly)
- Tuesday: $14 coffee and lunch (discretionary, near office)
- Wednesday: $210 electric bill (recurring monthly, expected)
- Thursday: $42 pharmacy (health, infrequent)
- Friday: $90 dinner out (discretionary, social)
The balance view shows a net decline of $424 across five days. The cashflow view shows something completely different: two recurring or planned obligations ($278) and two discretionary categories ($104) and one health expense ($42). A PFM app with cashflow signals can separate "spending you already knew about" from "spending you chose in the moment." That is the distinction that changes behavior.
Recurring detection is the first critical layer: identifying which transactions are repeating, on what schedule, and with what expected amount. Without this layer, every charge looks like a discretionary decision and the user's spending summary is noise. With it, the app can present committed spending (rent, utilities, subscriptions, insurance) separately from variable spending, and the variable category suddenly becomes actionable.
The Data Structure Difference
A balance snapshot is a scalar time series: one number per point in time. It is easy to store, easy to retrieve, easy to display. The problem is the information it carries does not decompose into useful dimensions.
Cashflow signals are an event stream with structured fields: amount, direction (debit/credit), timestamp, merchant identity, category, recurrence flag, and confidence. When you query this structure, you can ask questions that a balance series cannot answer:
- How much did this user spend on dining in the last 30 days compared to the prior 30?
- What percentage of monthly outflows are committed (recurring) vs. discretionary?
- Which categories are trending up month over month?
- What is the expected outflow for next week based on detected recurring patterns?
None of these queries are possible against a balance time series without essentially reconstructing the cashflow event stream from the differences. And that reconstruction is lossy: the balance difference between Tuesday and Wednesday does not tell you whether the outflow was one transaction or seven.
Building on Top of Enrichment
The reason most PFM apps default to balance views is not that their product teams think balance history is the best insight. It is that balance data is what open banking APIs return directly, and it requires zero enrichment. Category-level cashflow views require the enrichment step: taking the raw transaction list and tagging each row with merchant identity, category, and recurrence status before any aggregation can happen.
The enrichment step is where most teams underestimate the work. Getting a transaction categorized is the first problem. Getting it categorized consistently across different string representations of the same merchant, across different transaction amounts and times, with a confidence score that lets you decide whether to include it in aggregations, that is a substantially harder problem than most engineers expect when they prototype a category model in a weekend.
When we look at integrations built on the Openaggr API, the teams that get good results fastest are the ones who build their data model around the enrichment response fields from day one, not the ones who try to retrofit enrichment onto an existing balance-based model. The difference: if your data model is balance-first, you store the enriched fields as annotation on top of a balance record. If your data model is transaction-first, the enriched fields are first-class citizens and aggregation becomes trivial.
What Good Cashflow Insight Looks Like in Practice
A mid-size neobank team we worked with during early integration had built a "spending breakdown" feature that showed a pie chart of category totals. Users looked at it, found it mildly interesting, and did not return to it. The team concluded that category views were not engaging.
After moving to a cashflow signal model with recurring detection, they rebuilt the feature around a different frame: "Here is what you committed to this month before the month started, and here is what you added on top of that." Committed included rent, utilities, subscriptions, and insurance, all detected as recurring by the enrichment pipeline. Variable covered everything else. The ratio shifted every month, and users started noticing it.
Engagement went up. Not because the data changed, but because the data structure changed. The committed/variable split is a question people can actually act on. "How much did I spend on dining" is a question people answer once and then find it hard to do anything with. "I spent 18% more on variable categories this month than last month" is information that connects to decision-making.
The Counterpoint: Balance Data Still Matters
We are not saying balance snapshots have no place in a finance app. They are necessary for the basic account status view and for detecting anomalies like large unexpected charges that drop the balance sharply. Fraud detection heuristics often start with balance-derived signals.
The point is that balance history should not be the primary presentation layer for spending insight. It belongs at the account level, as context for the cashflow view. "Your current balance is $2,400, down from $3,200 last week" is meaningful in the context of knowing that $780 of that was expected (rent installment, utility bill, weekly grocery run) and $20 of it was a new discretionary charge. Without the cashflow signal layer underneath, the balance context communicates anxiety but not understanding.
Practical Notes for PFM Teams
If you are building a PFM feature on top of open banking data, the sequencing that works in practice is:
First, enrich every transaction on ingest. Do not store raw strings and plan to enrich later. The enrichment fields are what make every subsequent feature possible. Batch enrichment through a webhook flow works well for backfilling historical transactions; real-time enrichment via the POST /enrich endpoint handles new transactions as they arrive.
Second, run recurring detection across the enriched transaction history before building any aggregation feature. The recurring flag on each transaction is what separates committed from variable in your spending model. Without it, every charge looks discretionary and your summaries will be wrong in ways that frustrate users.
Third, build your UI around cashflow events, not balance points. The charts that drive engagement in category-aware finance apps are bar charts of category spend by week (not a balance line), and period-over-period comparisons by category (not account total). These are only possible when your underlying data model treats enriched transactions as the primary unit.
The balance snapshot is what most open banking APIs give you for free. Cashflow signals are what you build on top of enrichment. The gap between those two things is where PFM differentiation lives.