If an app shows only how much money is there right now but ignores the obligations already moving towards that balance, it gives the user a distorted picture of reality
One of the most underestimated mistakes in digital banking is the assumption that the current balance already gives the user a meaningful picture of their financial state. In practice, it is far too weak a signal for decision-making.
The problem is that a balance shows only the current state of the money, but says almost nothing about what is already moving towards that money next. Rent, subscriptions, recurring charges, transfers, and other obligations exist as future pressure long before they actually hit the account. But the interface usually keeps showing one calm number - as if that were the whole picture.
That is exactly why current balance so easily creates a false sense of control.
From a UX perspective, this is not a minor interface flaw. It is a structural weakness in the product. If a person is making decisions based only on how much money is there right now, without seeing that the balance is already about to stop being enough, then the product is effectively helping them navigate from an incomplete state of the system.
In my view, a good banking product should work differently. It should not only show the money available at this exact moment, but also see in advance the point where obligations begin to consume the available flow. Not scare the user with a stream of anxious alerts. Not turn the interface into a showcase of “smart analytics”. But simply and in time show where the risk of a shortfall is starting to form.
That is where the line sits between a passive financial interface and proper financial navigation.
In DARCA, we look at this as a basic everyday banking UX task. If the system understands the obligations a user already has, it should be able to warn them that the available funds may not be enough - before the problem turns into a missed deadline, a failed payment, or an ordinary cash shortfall in everyday life.
That is why, for us, forecasting a shortage of funds against obligations is not “extra analytics”. It is one of the basic things a good banking product should be able to do.
Because users do not only need an answer to the question “how much money do I have right now?”
They also need an answer to the question “will this money be enough for what is already moving towards me?”
1700+ people have already received access to DARCA testing, and we are continuing to open access further.
If you also want to join testing, here is the link:
https://forms.gle/toKvRjDVEheJEddV7
What do you think is more useful for everyday banking UX - showing the current balance as the main reference point, or warning users in advance that obligations are about to start consuming it?
Top comments (1)
Really well-articulated framing — the "current balance as a single calm number" problem is something we run into constantly in bank data aggregation.
From the API side, PSD2 Account Information Service (AIS) endpoints actually give you the raw primitives to solve this. The standard Berlin Group and OBIE payloads expose two balance fields: bookedBalance (what's settled) and pendingBalance (what's in flight but not yet cleared). Plus the transactions endpoint gives you both booked and pending transactions with value dates. So the data to build "projected balance after known obligations" already exists in the bank's own API — most apps just don't use it.
The harder part is what you're pointing at: combining that across multiple accounts and sources. Someone with a current account, a savings buffer, and a credit card has obligations hitting three different rails at different settlement speeds. A single-balance view is noise; an aggregated, forward-looking view is signal. That's the UX gap worth closing.
I work on open-banking.io (full disclosure) where we focus on the aggregation layer — pulling AIS data across EU banks into a normalized API so builders can get at exactly this: booked vs pending balances, upcoming direct debits, and inter-account cash flow without implementing hundreds of bank-specific integrations. Not pitching — just nodding that the primitive you're describing (obligation-aware balance) is the right one to build on top of.
One thing I'd add: the "false sense of control" problem gets worse with aggregation, not better, if you surface five account balances without context. The UX challenge isn't showing more numbers — it's showing the right derived signal (projected shortfall window) from the raw data.