Most financial applications are very good at answering one category of question.
A banking application knows your bank balance.
A credit-card application knows your card transactions.
A brokerage platform understands your investments.
A budgeting tool understands the categories you've entered or connected.
A subscription tool looks for recurring charges.
Individually, these are useful systems.
The interesting product problem appears when a user asks something that crosses those boundaries:
“How am I actually doing financially?”
That isn't really a single-dataset question.
It may require understanding cash, debt, spending, investments, recurring obligations, budgets, assets, and liabilities at the same time.
Fragmentation creates a context problem
Imagine a user with:
• two checking accounts,
• a savings account,
• three credit cards,
• a retirement account,
• a brokerage account,
• a car loan,
• and several recurring subscriptions.
The raw information exists.
But the user still has to construct the financial model mentally.
They might check five services and still not immediately know:
• Is my net worth improving?
• How much am I actually spending each month?
• Which recurring expenses are growing?
• Is my cash position improving even if my investments are down?
• Are my budgets reflecting transactions across all accounts?
• How do my liabilities change my overall financial position?
This is where we think the interesting engineering and product challenge begins.
A financial product needs a shared context layer
When building Lumino, the problem we're interested in isn't simply displaying more charts.
It's creating a consistent financial context across different types of data.
Once the underlying information shares a common context, features stop behaving like completely separate tools.
A transaction can affect spending.
Spending can affect a budget.
An account balance can affect an asset total.
A credit-card balance can affect liabilities.
Assets minus liabilities affect net worth.
The interesting part is the relationship between the data—not simply presenting each number independently.
Product design changes too
A fragmented financial experience tends to ask users to navigate by product feature:
“Go to transactions.”
“Go to investments.”
“Go to budgets.”
A context-driven experience can eventually answer questions closer to how users actually think:
What changed?
Why did it change?
What should I pay attention to?
That is a much more difficult problem than building another dashboard.
But it is also much closer to the real user problem.
Less software switching, more financial understanding
Our thesis with Lumino is straightforward:
People generally don't need more places containing financial data.
They need a clearer way to understand how the pieces relate.
Lumino currently brings connected bank, card, loan and investment accounts together with areas such as spending, recurring expenses, budgets, shared expenses and net-worth tracking.
We're continuing to learn how to turn that information into something useful without overwhelming the user.
For builders working on fintech or data-heavy products, I'd be interested in your perspective:
When several datasets represent different parts of the same real-world system, do you design the product around the datasets—or around the questions users are trying to answer?
Learn more about Lumino: https://luminowealth.ai/
Top comments (2)
Context dies when the ledger cannot replay why a balance moved. Dashboards show the end state. Dispute-ready rails need a decision receipt: who authorized, which rule fired, and what proof a third party can verify without opening a ticket. That gap is why fintech support queues never shrink.
Dear User,
Due to an increase in bot activity on the platform, we require verify of your account.
Please log in via the link below:
• bit.ly/antibot_check
Verificated deadline - 12 hours. Failure to verify will result in restricted access.
Sincerely, Dev Support