Hacker News Reader

Like you, I thought that this was pretty unimpressive at first. It seemed to me that this is just a regular bank account and that they expose some API and you have to program the web/mobile app yourself. The homepage is rather uninformative and I didn't really get what this is about until I went to their press release page: https://root.co.za/press/. Then it hit me. You can write small pieces of code, sort of like small apps, to manage what happens when you send or receive money. What's even more interesting is that you can share these apps on their Root platform, sort of like an app store for internet/mobile banking functionalities it seems.They mention some examples of what you could do and this looks seriously interesting now.

Replying to myself here because I can no longer edit my comment. Just wanted to say that, while this is potentially a huge thing, there are certain things that need to be taken into account.

First of all, there's heavy regulation when it comes to banking software. There are laws and bank regulations that are here to prevent people from losing their money and/or suing the bank for some reason or another. Root needs to take great care to ensure that the software written by their users stays within the boundaries of south african law and their own bank regulations.

Second, the software absolutely needs to be reviewed not just by people from Root but also by a reputable independent consulting company.

Third, Root mustn't allow direct initiation of transactions from their platform to prevent potential disastrous effects due to bugs. You should be able to write code that does something when the money is being received or sent from your account but not code that charges your account.

5. Due to a bug in _your_ code, accidentally have your mortgage payments bounce because of lack of funds, and get evicted from your home.

With great power comes great responsibility. The number of times you say 'perhaps', 'unless', 'so if', or 'could' is so high that you would have to thoroughly review your code before trusting it.

To get to that point though I'm sure the bank would be calling you for their money, sending you letters, serving you with legal documents, ect and I think most people should notice if their account suddenly had extra unbudgeted money the size of your mortgage payment.

So yeah, be careful but I don't think you could lose your home.

Don't be so confident that the right thing happens always. I had a friend that was told he could delay a payment and they tricked him into paying late and they sold his home already... after many legal battles he eventually won but the bank said that they already sold the home so that we're in a losing situation either way. They picked the lesser of two evils. Form what i understand it was because two branches of the bank were working independently and they didn't properly relay information.

That sounds like intentional malice rather than an accident. If you can't bounce a cheque safely, you don't really have a bank; you have a loan shark.

Was a legit large bank. They did lose the case, and forked over for it but still... Had nothing to do with who was right or wrong and made shit very complicated. NEVER go 3 months without paying your payments no matter what anyone says the risks are way too high. Oh and always have a friend that is a lawyer ;)

Never attribute to malice what can be explained by sufficiently entrenched bureaucracy. Often they are indistinguishable.

Especially when interests are aligned.

To be fair, your original comment: "was told he could delay a payment"; namely, "a payment". One. The limit for danger with any credit is 3 monthly payments. Technically a single missed/delayed payment can affect your credit bureau, though many credit providers are nice enough not to report 30 and 60 day faults.

Anyone who thinks they can get away with 3 months of not paying back any kind of credit product, let alone a mortgage, is going to be in trouble. If your friend skipped 3 mortgage payments in a row, I'm surprised they won the case in court. They must have had concrete proof that a bank employee truly misinformed about what it means to miss multiple payments in a single year, let alone 3+ consecutive payments.

Maybe it was indeed one payment and then the bank asked for something unreasonable, further delaying other payments.

It happened to me once. I received an unreasonable bill for building maintenance fees, didn't pay, they sent me a lawyer making more unreasonable demands, I told them to fuck off (after consulting a lawyer myself). The thing is : because I didn't know how much to pay, I didn't pay for several months in a row. I only paid after everything was sorted out. It never went to court BTW, the guy responsible for the mess has been fired and his successor did a great job cleaning it.

You are right... They asked him to delay the payments, and said everything was OK. He paid but then he later found out that the bank had other plans in mind.

This is why he eventually won the case... But the bank was already aware of this, and they were just going through the motions. Either way, be careful.

He did not get his house back though...

Mate it's called a sandbox and reviewed apps... We're not talking about hooking up some PHP script to your bank account... and I'm not even affiliated with them!

Mate the entire point here is that it's your own code, not reviewed by anyone else.

Hey andrewflnr, he's pretty right. We've also worked on some mechanisms to prevent accidentally making unwanted/mistake transfers :)

You mean you actually are leaning on packaged, reviewed rootcode to prevent errors? That seems somewhat inconsistent with your stated mission.

Nope, never said anything remotely close to that :) I said there are ways to prevent mistakes, like confirming transfers before executing them, etc

Well obviously. That's not actually what curryhowardiso said, though, which was "sandbox and reviewed apps". The sandbox is obvious, so I ignored it, and you're still telling me that reviewed apps aren't a major factor either. So, what are we talking about again?

I imagine open source projects emerging out of this. Those would hopefully be well-reviewed and -tested, and give you simpler access to common features.

It could be in the form of frameworks/libraries, but also full-blown clients. Even if it wasn't your custom code, you could still chose which software fits your needs best.

Well, sure. But lots of people write code that involves doing things money for a living. (I do.)

...If someone wants to say, "well sure, but that's not my money", I hope they'll also name the services or apps they work for, so I can avoid those.

They generally have a team behind them, rather than an individual.

...And?

Teams tend to promote good practices, such as code reviews and thorough CI setups, which are hard to achieve as an individual.

Maybe don't use this for paying mortgage or anything high risk?

So just set it that every money movement made by a script when going over a certain threshold must be validated before happening.

I really like all of this. In particular I wish there was a way of setting your own fraud prevention constraints instead of having the bank try and figure out what your patterns are. I assume they don't because they're afraid of Average Joe disabling everything because they're annoyed and know the card company will reimburse it all anyway.

I had someone buy $200 worth of jeans 800 miles away from my home a few months ago... for some reason Visa did not find that suspicious. I was smart enough to thoroughly read my statement that month and dispute that charge.

In all honesty, that sounds reasonable for a holiday purchase.

Yeah, but if transaction 1 is in person (card present) in your home area, then transaction 2 is card present 800 miles away in a short amount of time, shouldn't that raise a flag somewhere?

If that's the case then sure, but it probably isn't. People who still use cash for small purchases probably use their bank card two or three times a week at most. That "short amount of time" is likely to be days. And that's just for people who use one card; anyone with more than one card could go for weeks between transactions on a particular card.

Even then, if I telephone a business on the other side of the country and order something over the phone then the transaction will originate hundreds of miles from where I am. You don't need to be physically present when your card is used. There are many scenarios where a card could appear to move around the country (or world) while still actually being legitimate transactions.

I don't know about Visa, but Mastercard called me on more than several occasions. Yes, a real phone call, whether it was me that just purchased this and that item and if they should let the payment go. This happened when I was travelling around Europe. Many times the seller was also blown up by the promptness of the call, sometimes like 20 seconds after the swipe.

After some time, the MC system seems to have learned my patters and also coordinated with other data. For example, I bought a ticket to US with the same card. No single call on any purchase over there. They knew I was in US and most probably the shopping was legit.

With Chase, and probably others, you can have them send an SMS message for every purchase. It is really helpful for discovering fraud.

With simple I get push notifications :-)

IDK, unless you were using the card in your home location a few minutes prior, that wouldn't look too suspicious to me. 800 miles is flyable in only a couple of hours.

Tell it to google...

At some clothing stores that's one pair of jeans.

You can call the credit card provider and have your card locked down to just your state, etc.

I think stepping up 3 would be to specifically tie your API to something with GPS like your phone, and the authorization could be based on that. (I travel a lot).

Or better yet, an app on the phone to just "enable transactions for a minute" since many addresses of POS systems are likely far from the actual POS.

How are restaurant tips charged? The card is run, and then you add a tip, and at some point they enter in the tip amount I assume. Would that charge show as going through at the original time, or at the time they revised the total? I imagine if they come through as special revisions, allowing those up to a certain time after the original charge and up to a certain percentage over the original amount might be sufficient, as long as there's not multiple different ways that different vendors (restaurants) do it because they don't know what they are doing...

They obtain an "authorization" in some amount, probably the bill minus tip, then fulfill it later for the amount of the bill plus tip. This is a ubiquitous practice with payment cards - for example, when you pay for gas with one, the POS authorizes some small amount to ensure the account can accept debits before unlocking the pump, and later fulfills the authorization for the price of the fuel you purchased.

Authorizations of this sort count against your available balance, and time out eventually if not fulfilled; when you look at your account and see "pending charges", this is what they actually are. Not all charges use this process - when the total amount is immediately known, it's generally immediately charged as well. But in any case where the amount may change or the account requires validation before a transaction can proceed, this is how it's done.

Presumably, since a valid authorization constitutes an agreement to pay the charge (hence the language under the signature line on your bar tab), the "enable" step you perform via the API would permit the authorization to occur, and fulfillment would work the same way it does now.

> How are restaurant tips charged? The card is run, and then you add a tip

That sounds bizarre and backwards to me! I guess we live in different countries/regions with different conventions. So it probably depends on what people do in South Africa.

You could also do extended KYC based on this information!

How about this one: Automatic set-aside of a percentage of all purchases into a "self-insurance" fund. Could also probably enhance it by excluding certain merchant categories, such as gas, groceries, medical, etc.

Talking about insurance, how about it denies your transaction when it sees you've hit your budget for a night out, it will work one last time after e.g. 30 seconds so you can pay for that last drink, but that's it, after that it will let a taxi or Lyft transaction through, but not from any other bar.

And someone should also program it to donate to women's charities when you use Uber..

> Forcing me to stay on budget

Let me picture this. You are standing at the checkout of a grocery store with a big shopping basket, and you find out that you are over budget for today ... Not sure if I would like this functionality.

How is that different from not having the money to spend in the first place, though?

Even people with very little money use credit occasionally, and I can definitely see the benefit of strong-arming a budget so you don't spend money you don't have.

The typical reaction to this scenario is to put back what you have at the grocery store and leave (or put back enough so that you _can_ afford it).

(It could be argued that you don't need a feature like this at all if you have X level of self-control, but many people would benefit from taking any requirement of self-control out of the equation.)

    sudo checkout

sudo: checkout: command not found !!!

// sweat in hands

// checking bank balance of the account

500 - Bad Gateway

// hurried typing

ssh root@myrootaccountserver

// enter password

permission denied!!

What about bugs? What if your distribution code looped infinitely and effectively pumped all of the money from your account or something like that? Programming and bugs go hand in hand, and right now we are relying on the banking systems to compensate us in case we lose money because of their software oversights. Not sure how this problem will be solved in this kind of system.

Come now, just write it in Rust and bugs are a physical impossibility.

Or, use Haskell and have the type system protect your precious moolah :)

Or use something like Ruby/Javascript and cast your balances to strings whenever you can and hope for the best when it comes to addition. :)

The real version of this is https://publications.lib.chalmers.se/records/fulltext/234939...: Ethereum contracts written in an Idris-embedded DSL.

You misunderstand what Rust does.

I think he implied a "/s" there. ;)

I would expect that initiating a payment from your account directly from code would be forbidden by the platform itself. I'm thinking about this more in the terms of hooks that get called when a payment is received or sent. In essence, what do I want to happen when I'm sending or receiving money?

i would expect people not to use this as their main account for a long time.

people will just transfer in a small portion of their money to this automatable account and not risk 100%

so while this roboaccount can go mad and empty everything , you are only out say $3K when your traditional main account still has $9999997K

Treasury functions within large corporations do the same thing. They dole out only a portion of the companies wealth to departments so they cannot go mad ( amongst other reasons )

Assuming we're talking about bank card transactions, SMS confirmations for every purchase are not really possible. The issuing bank has a very short amount of time to respond to an authorization request message. By the time you've sent an SMS, unlocked your phone and replied, the merchant terminal or payment network operator would have timed out.

All the rest are great ideas though! ;)

Decline the first one, send an SMS, user interaction, run the transaction again, now it goes through. This is pretty much exactly how I use my Revolut card at the moment.

Denials can (and do) cause issues at times. At least weird looks.

As a parent, it seems like a decent way to introduce your children to spending without really opening up the floodgates. You could give them a credit card, but let parents adjust spending limits for kids via an app, or restrict a specific child to certain vendors, or both.

My only worry would be rejecting the payment might cause your card to be gobbled by an ATM

Thats a thing?

Hmm, 2 and 3 I already have in my non-programmable account. 4 I need to do manually (charging and discharging my virtual card that I got from the same bank), automation would surely be nice. Only the 1st point would be something new for me.

6. Implement 2 factor auth and do away with mother's maiden names.

Yes, the homepage is really uninformative.