To be fair, that is true now. However, based on the previous features it wasnât true back then
But those types are useful if Monzo is ever going to hit their huge customer account number aspirations.
I didnât comment on the value of them to Monzo. Only Monzo knows their business model. Only that the product isnât a good fit for them
Well the value is that they convert those prepaid into current accounts that are used as a current account and continue forward as a sustainable customer.
Bit like myself l was only looking for a prepay product now l am close to having Monzo as my primary account. Value is converting accounts, some will drop off yes if they did opt for a free fee card for overseas etc.
If Monzo didnât recognize the attractiveness of their original terms and the potential for conversions why offer it in the first place if uneconomic?
I canât guess at what others do. One thing tho, lessons are learned by startups. I doubt they banked on just how much the MSE crowd can withdraw at foreign ATMs
Be interesting to know what the hurdles are to achieving stable DDâs and sign up to the CASS.
Is there any instability with Direct Debits? I knew standing orders could have issues but I havenât seen any mention of any Direct Debit issue on here that isnât explained by NSF.
An obvious hurdle to CASS is Merchants & Banks Who Don't Yet Recognise the Monzo Current Account Sort Code / Debit Card (open Wiki)
There are plenty of large companies there basically saying that they refuse the believe monzo even exists⌠how would they handle a CASS request? Theyâd more likely just bounce it, causing pushback to monzo as itâd be seen as their fault.
I think Graham is talking about the issue where DDâs get declined straight away if your account balance is insufficient as opposed to other banks where they will be retried up until a cutoff time usually by the end of the day. It definitely is a change from how legacy banks do it but makes total sense when you look at it from a technical point of view - a DD event comes in, some code checks balance and either returns success or failure depending whether the balance is sufficient. Being able to retry them would mean adding extra code (to queue up DDâs, and a check every time the balance updates to see if itâs high enough to process the queued up DDâs), which they will certainly come around to doing in due time.
Ah yes, I knew about that issue, (NSF, non-sufficient funds) but @Demmedelusive said stable DDâs, so that implied instability (not simply the no retry for NSF issue). I havenât heard anyone report any stability issues.
I am actually not sure if that would be an issue; a lot of sort-code acceptance issues were due to the fact that most user-facing tools stupidly insist on validating the sort code against an out-of-date list instead of just trying them and see if it bounces like they should be doing (does your phone try to validate every single number you call/text? No, it just tries to call and tells you if that fails).
I assume that in case of CASS there will be no such logic (if a CASS message comes in it means the bank exists and sort code must be valid, no need to check especially given there is no room for human error in this completely automated process) so it should be just fine - the Monzo sort code itself is valid and any payments will successfully work against it, itâs just a matter of getting it in the database and bypassing stupid validation, which CASS should be able to achieve.
Youâd hope, but it depends on how the CASS message reaches those companies that use a 3rd party processor⌠if they just forward it on and the processor uses the same broken validation, chaos ensues.
If the system were sane they wouldnât be validating it in the first place, except maybe a check digit or two.
I am yes, Andrei. Unstable is the wrong word. The CASS thing seems to be even more of a mystery (in the absence of any narrative around the actual process of establishing it).
Donât know how long it took Starling to achieve it. It may have been a lengthy process behind the scenes. I wonder, as is suggested, whether the presence of the pre-paid card has got in the way. I wonder, indeed, quite what the process is?
It matters because itâs frustrating folk - and preventing full adoption of the CA.
But in this case I donât see any reason to validate it in the first place, bad data should not arrive via CASS to begin with, as getting access to the BACS network (whatever that is, no idea what technology/protocols are involved there) implies you have a valid sort code already. I could kinda see the point of validating in the early days when bad details mean DDâs fail and notifying customers would be done by mail/fax/phone call, but nowadays bad details should simply mean an automated email/SMS with a link the customer can use to update them and try again.
Starling has CASS and seem to be doing fine despite a fairly new sort code, at least I havenât heard of any issue regarding their sort codeâs acceptance via CASS which seems to support my theory of no sort code validation on CASS like it should be.
I think the reason Monzo is putting off CASS is to work on migrating existing prepaid users ASAP (as theyâve got a deadline after which they turn off the prepaid scheme entirely), and CASS wasnât part of the prepaid so no loss of functionality there, so to be honest I agree with Monzo that CASS is not that critical. Starling is a different story as they started as a current account to begin with so CASS was there out of the box.
Wrong, it absolutely does do some basic sanity checks. For example, a lot of people write their numbers as +44 (0) 20 XXXX XXXX. Thatâs not a valid number and if you dial it, it wonât work. you either write +44 20 XXXX XXXX (international format) or 020 XXXX XXXX, not both combined. My phone will automatically remove the 0 before sending the number. iPhone calls this âdial assistâ.
Thereâs other parsing too, emergency numbers are detected to put the phone into emergency mode. Crisis helplines are often removed from call history, etc.
So yes, yes my phone does do exactly thatâŚ
Two sort codes in fact.
Well dial assist is good, but it only tries to help out when possible and still lets through the typed number as-is if it canât figure out how to âassistâ (and it can be disabled if it becomes problematic). In the case of sort codes itâs a hard fail with no way to override which is not ideal.
Sort code validation can be helpful but shouldnât be a blocker. If you canât recognize the code, give the user a heads-up but allow them to override it (by submitting the form again) if they really know what theyâre doing. Plus your system can learn new sort codes by itself without any manual intervention, as any unknown sort-code that successfully processes a payment can be automatically added to the list of known codes.
Hereâs an example of e-mail domain validation done right - companies should be doing the same for sort-codes. It suggests a correction if it thinks your email domain is invalid (gmail.con instead of .com) but still lets you proceed with the original one if you are sure.
Direct debits are actually defined in terms of a multi day batch process with a cut off at the end of the day
I donât recall the exact details off the top of my head but due to for they are designed to be implemented it is actually true that the Monzo flow as it is, is quite unnatural
Yep, I never said the Monzo flow was usual, just that it made prefect sense when you look at how Monzo technically works - is event based, so when a DD comes in the event is processed right away instead if queuing up and processing it in batches at the end of the day like old rust does it.
I hope that in future Monzo so implement a âbest effort of successâ approach to things like direct debits where they can - it seems like the best user story to me
For example, due to Monzoâs event driven architecture I could imagine whenever a positive balance change occurs that may be a good time to check if there are any unactioned direct debits that can now be processed forward
This solution to me is significantly better than the âdo it at certain hard coded times of day as batchâ approach