PreMoneyProduct story · 4 min read
A bank message is not always a clean transaction.
A personal-finance app that converts bank and UPI messages into reviewable transactions, categories, and summaries.
Read the case study
Actual Android dashboard with no transactions. Scores stay unavailable until there is enough information; SMS access was skipped for this capture.
View full size ↗01 The problem
How should automatic tracking admit that it is unsure?
Manual expense entry asks people to repeat information already present in transaction alerts. PreMoney explores a more useful starting point: extract likely transactions from messages, then make uncertainty and correction part of the workflow.
Designed for Person reviewing everyday spending. Trust the record enough to review and correct it.
User context Design assumption
Using transaction alerts to understand money movement.
- The friction
- An ambiguous alert can become a plausible but incorrect transaction.
- Design implication
- Make uncertainty visible and correction recoverable.
Example situation · illustrative scenario. Imagine an expense app reading a bank alert. Automation has saved an entry—but if it guessed the amount or merchant, the summary now looks more certain than its input.
02 The direction
Uncertainty should stay visible
A reviewable uncertainty is useful information. Confidence, rejection reasons, and unresolved merchants give correction a place in the workflow.
Product artifact · transaction confidence and review
My direction. I framed the journey around inspecting and correcting a suggested transaction, with separate explanations for optional categorisation and sync.
Process and product scope
I framed the core journey as evidence, suggested transaction, review, correction, and summary. A person should be able to understand why an alert became a record and recover when the interpretation is wrong.
Privacy explanations belong alongside optional categorisation and synchronisation. The experience needs to make those choices understandable without relying on a blanket claim that all processing stays on the device.
- SMS
- transaction input
- Confidence
- visible in parser model
- Review
- unresolved merchants
- Read
Distinguish an account movement from other alerts.
- Flag
Keep uncertainty in the transaction model.
- Correct
Inspect the origin and improve the record.
03 Design decisions
Make uncertain transactions easy to review.
Open a decision to see the reasoning and trade-off.
01Prefer an uncertain result to a fabricated detail
The parser lowers confidence when a field is uncertain and records when a merchant is unresolved.
Why this matters. A plausible but incorrect financial record can be harder to notice than a clear request for review.
The trade-off. Conservative parsing can miss legitimate alerts. The product needs a recoverable route for false rejections.
02Make correction useful beyond a single transaction
Transaction editing and review make suggested categories and corrections inspectable.
Why this matters. Repeated mistakes should become easier to diagnose than manually editing the same pattern forever.
The trade-off. A learned rule can also propagate a wrong assumption, so its effect must remain inspectable.
03Treat enrichment as a separate data decision
Optional categorisation and synchronisation need a separate explanation from reading a transaction alert.
Why this matters. People need an understandable account of which data is used by which feature.
The trade-off. The product documentation describes external processing paths; disclosures and controls need review before making privacy promises.
04 The outcome
A suggested transaction, open to review.
I designed a route from the original message to a suggested transaction, correction and summary. The important part is being able to inspect an entry’s origin and fix it when the interpretation is wrong. Accuracy needs to be evaluated against a defined set of messages.
More about the experience
- Confidence is a design input. Ambiguous transaction alerts need an explicit review path before a record feels trustworthy.
- Correction has a home. The app includes transaction editing and review.
05 Reflection
Automation earns trust by making its uncertainty correctable.
I would start with a wrong amount, a duplicate alert and a message that is not a transaction. If correcting those cases is difficult, adding more charts will not make the financial record more dependable.
What I would evaluate next proposed work
- use a consented, redacted alert corpus to measure false accepts, false rejects, duplicate errors, and corrections by bank format.
- document the external-processing and sync paths, then test whether a person understands and controls them.
The song waits until you are ready.