These lower authorisations, followed by a larger amount being debited from your card obviously makes it much harder to manage your balance. This issue could partly be solved by enabling users to set aside the actual amount that’s due to be debited from the card, a variation of this idea
but that would be a manual process.
Does Mondo know what the final amount that will be charged will be? If so, is this the amount that’s displayed in the transaction history & which is deducted from the account balance?
And if not, how can these pending transactions be managed, to enable the user to ensure that they always have enough funds on their card to cover these pending payments?
The authorisation charges are usually refunded within 10 days. Though you can ask Mondo for a quicker refund. If the merchant delays a transaction, Mondo has no way of knowing the final amount before its charged. Currently both the authorisation charge and the amount would be shown in the feed. Once the refund is issued, that would also be shown in the feed.
I don’t have a problem with being charged the authorization, it’s having a way to manage my balance to ensure that I have enough money on my card to pay for that final charge for the full figure that I’m looking for here.
That only you and the merchant would know. There is no way for Mondo to know that. Ideally you should have enough funds for both the authorisation charge and the delayed full amount. Although you might get away if you ask Mondo for a refund quickly.
The problem is, it’s easy to ensure that you have enough funds for the full amount when you make the purchase but it’s also easy to forget that that higher charge is pending and spend those funds in the meantime…
If Mondo doesn’t know the amount that will be charged, I’m hoping we can come up with some ways to manage for this i.e
I don’t think any of these solutions are perfect, these are just ideas to get the ball rolling
Manual edits of transaction amount (probably not a good idea) or a second field, to record the pending payment amount which can be totaled & viewed in reports / alongside the current balance
Building on Optical Character Recognition, as suggested here, to enable :mondo: to extract the final amount due & set that as the transaction amount (since pending transactions are displayed in the app initially anyway, before they’re settled)
Setting aside part of the card balance for upcoming payments (see my initial post)
I agree with a lot of the points you’re making & I appreciate you sharing your knowledge on this but notes aren’t enough and I think you’re underestimating the significance of this challenge for some users, especially when it’s getting towards the end of the month and you need to ensure that you don’t go into your unplanned overdraft.
Another incentive for :mondo: to address this that they want to offer users overdrafts when they’re in danger of running out of funds before payday.
But if :mondo: doesn’t know the full amount that’s due to be debited from the user’s account & that this will put the user at risk of running out of funds, it’s automation won’t know to make the offer…
I think your suggestion pretty much falls under the concept of “Virtual accounts”, which I think has been suggested before.
The ability to split up the account into multiple sub-accounts, with both automated allocation of money (eg: At the start of the month, set aside £X for expenses) and manual (Pretty much what you’ve described here), would be a powerful one, but it’s a tricky UX to sort out I can imagine!
Mondo makes predictions based on your spending. If you have more or less a regular income, then the pulse graph can predict when your balance would go to zero. If this is before the next payday, Mondo can offer an overdraft.
Again, Mondo cannot know how much a merchant is going to charge your account, unless you tell it. Which creates more problems. You can claim that a payment is about to be made, and if Mondo based its decision to provide overdraft, people can fool it.
I’m not sure this would be user friendly enough to manage this particular use case. You’d have to manually update the money set aside each time you had a new pending payment & when that payment’s debited. Or keeping a large enough reserve in a separate account to cover any delayed payments isn’t feasible for the user who’s about to run out of funds, who is my primary concern here.
I want to argue against this from the point of view of status quo i.e. It’s the way every bank account works now and people cope fine.
What’s being requested, however, is exactly how I use my current financial software so I can’t really argue against with any credibility!
The only concept for this in my head is the ability to support manual transactions (in the app) alongside the bank transactions. Matching the manual tx up with the automatically downloaded tx then becomes yet another function for the app.
Pros:
No fiddling with ‘bank’ data.
Cons:
If things don’t match up then we’re left with a pod of old data that needs to be cleaned up.
The app needs to maintain ‘Actual’ and ‘Available’ balances to split ‘real’ from ‘user’ txs. These totals will only agree if you’ve been using instantly posted transactions exclusively
I’m just not sure how the complexity of this would fly with Mr Everyman
Since the later charges are still logged against the initial transaction record, automatically clearing the manually entered value, once the system’s transaction amount changes, could be a solution?
It all depends on how the matching criteria are defined. As we’d be potentially letting users enter business names etc it opens up a whole host of potential errors from spelling onwards.
Clearly if the app couldn’t match things then the user could do it themselves but if they don’t?Maybe they automatically get deleted after 30 days? (I’m assuming a matched manual transaction is deleted in favour of the official bank data)
Of course you could just match name and date for example and ignore the value or you could come up with all sorts of other ideas. I don’t know, it still feels like a fairly ugly bolt-on to me but I haven’t got any further than that.
Yeah I don’t think enabling users to enter new transactions is feasible because of the issues you’ve mentioned & there’s probably others too but actually, I don’t think that’s necessary.
The initial transaction record that I was referring to is the equivalent of the active card check (or the same as that, I haven’t made enough of these transactions myself yet to be sure) which you see from TFL etc.
So you have that entry in the database & in the app so you could record the pending amount in it, in a separate field. Then once that entry’s updated, when the full amount’s debited, the manually entered figure could be deleted. Would that make sense?
But taking the TfL example, I think you only et the initial check the first time you use it. Thereafter you get nothing at all so it’s surely manual entry or nothing for every day other then the first.
As I say I just haven’t seen enough of these transactions to be sure of the way they work. But if that’s the case then there would have to be a different approach
But essentially all :mondo: would need to do to support the solution I’m proposing is create an entry in the user’s transaction log every time the card’s used, for the user to log the final amount against, which they must do already in the database, to record the authorization.
They must have enough information that entry to tie it to the payment when it’s finally taken because it’s needed to reconcile the authorization with the debit (they definitely did for my first TFL transaction - active card check was 10p, entry updated several days later with final charge).
Simple answer will be Monzo to have not only an available balance set on actual transactions but a user defined adjusted balance where they can click on the available balance figure and then a minus icon to reduce the available balance to a lower figure…like the top up function in reverse
Would it be feasible for Monzo to let you select the pre-auth transaction and enter a final amount to be ear-marked until he transaction is complete?
The marked amount would not actually adjust the balance of the account but the user could be warned when they are getting close to 0 + earmarked amount. This could possibly be worked into the virtual savings account idea which is on the roadmap.
As has been said before, if the bank hasn’t been given the transaction amount by the merchant they really can’t be expected to account for it in your balance.
@anon44204028 your suggestion would work fine but my concern is keeping track of why your adjusted balance is the amount that it is. You need to see what the pending payment is for so that you can see when it’s been paid.
@Andy1 I was hoping that tagging the payment onto the authorisation / active card check would work. But it turns out merchants don’t do the check every time so you wouldn’t always have an entry in your feed to work with.
When I first created this topic I was more worried about having the funds available for payment but you’ve both pointed out that there needs to be some sort of secondary balance showing the accounting for the total amount from upcoming payments (this would include Direct Debits) too
As Andy mentioned, I think we can agree that the user’s going to have to manually enter the amount that’s pending so that’s fine. Users wouldn’t ever have to record these payments if it wasn’t worth it for them & they’re fairly rare.
The piece that’s still bothering me is how to reconcile the delayed payment with the amount that’s been set aside. You don’t want to have to manually update the total that’s been set aside. Hugo doesn’t like manual (& neither do I). So here’s my proposal -
Users can create feed items & record the amount that’s due to paid.
When they create the feed item, they’ll also have the option to search for the merchant that the payment’s due to be paid to. The search will auto-complete & if an authorisation was the last transaction, that payment’s merchant will be suggested. When another payment’s taken, the amount will be deducted from the total pending payments for that merchant. The merchant’s group Id, will be selected by Monzo when the user creates their entry so regardless of the location / id of the merchant who takes the final payment, the pending payment will be matched with the final payment.
The pending payments would need to be flagged in the list of transactions so that users can review them easily & update them if necessary.
The balance minus the amount set aside would be displayed as a secondary balance as @anon44204028 suggested & the user would be warned when they’re getting close to their balance minus the amount set aside, as @Andy1 suggested.
I try to avoid describing a solution in this much detail, as I’m sure Hugo can come up with something better. But since we haven’t heard from Monzo on this, I guess we might as well
