Hacker News new | past | comments | ask | show | jobs | submit login
Root – Programmable bank account for software developers (root.co.za)
1015 points by s_dev on May 3, 2017 | hide | past | favorite | 409 comments

At first I was wondering what I could possibly use this for, but as I sat and thought about it, I realized the possibilities are enormous. I'd like to know if the following are possible:

1. Forcing me to stay on budget, unless there's an emergency (perhaps allow purchases over budget after the third attempt).

2. Automatically distribute paychecks or other income into different accounts (some to retirement, some to savings, some to checking, w/e...); this behavior could change based on the current distribution of your money too, so if your "emergency fund" got really low you could automatically spend more of your income replenishing it.

3. Deny unwanted transactions and tightly control your own fraud detection (SMS confirmation for every purchase out of your zip code, confirmations for purchases from new places, you name it...).

4. Automate the creation and destruction of virtual cards to minimize danger of online purchases or to make sure that "free trial" never starts charging you.

I'm sure there's tons of other awesome ideas, but I want all of these quite badly.

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.


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.

People asking about what problem this solves haven't been to South Africa or Zimbabwe which in some ways are ahead of the West in creating cashless societies.

The biggest bank is a phone operator and people can send each other money over the phone and from what I understand this is very common. Also interestingly most phones aren't smart phones. It's mostly analog. Banks have a serious incentive to create and encourage cashless societies -- because they're limited by the liquidity ratio.

People there are more skeptical of hard cash there while here it's nearly on par with Gold in terms of confidence.

I don't think I've to explain offering an API allows third party engagement and endorsement and an opportunity for others to grow their service. Yes there are security concerns but these can be all secured from backend.

Let me counter with these facts about banking in South Africa:

1. Fees at most banks are high. (A basic account with no transactions typically have fees of several dollar per month).

2. If people are moving away from physical cash, its because of security concerns (theft and robbery), not liquidity.

3. Most transactions are done by credit card, debit order or Electronic Fund Transfer (EFT). EFTs are done between numbered banks account. Mobile to mobile phone transfers are still very rare.

4. People are stubornly loyal to their banks. If root fails, it will be cause of this.

Regarding # 4. This product is by one the current largest banks in South Africa. Standard Bank of South Africa is big in S.A and operates in many other African countries.

Just to clarify #2 - I read that as meaning that liquidity is a reason for banks to like the move away from physical cash. Why customers like it is clearly security, though, you're right.

Have you opened a bank account ins South Africa? If so, what economic bracket do you belong to?

One of the issue with cashless is that banks/financial service provided making money of of the money i.e. $100 making more than $100 with out adding any real value in fees (100 time circulation). I know time is money in most western countries but my place we do one crop a year and sit idle for 9 months. So time is not a money and we would rather give cash to a person get that much worth of a product.

E.g. My sons school charges 2% extra if i use credit card, Rs 20 if i use netbank and does not accept cash. So on a Saturday i am happy pay in cash when i have nothing else to do.

Unless government makes the transfer without fee (now they can print less money and that cost can be used for this infra of transfer), why is cashless better in the scenario where that saved time is not used for anything value generating?

Genuinely looking for answers to this that makes sense rather than saying time is money.

The example of your son's school is fine, but imagine that your son lives in another country. Cash has other problems beside being slow. It's insecure - a person could steal your $20 bill from your mailbox or his, or from the Post Office. It's untraceable - if your son's school says "We never got your payment" but your son swears he gave them the cash, you're stuck in a situation where either your son or the school is ripping you off (I'm sure your son would never do that). And last, it takes both time and money to convert cash to another currency. Taking the cash to somewhere where a person can convert it to the preferred currency is bad enough, and then it costs you money on top of it.

> It's untraceable

Feature of cash, not a bug. It's not the best choice for every situation, but neither is digital, which is why it's important that people have both options available.

Yeah, the ability to make payments outside of the scope of the panopticon is one of the better arguments in favor of cash and against a completely cashless society.

I'd like to think that in time someone will solve this too by some kind of clever obfuscation, but it's not going to be BoA doing it. It's going to be someone who wants to fuck with their status as a state-sponsored usurer. Or at least I hope.

Also consider Bitcoin as a "cashless society" alternative to the financial panopticon - no one's looking over your shoulder there and it's definitely not "cash".

I'm skeptical about Bitcoin as a potential alternative because I suspect that, if you combine the surveillance abilities of the state and the money of the state with the time and effort of the very many clever people who work for the state, Bitcoin will become substantially less anonymous.

Usually traceable unless you use a tumbler to "clean" your coins, even then it's still traceable I think

If it's digital, it's traceable. If it passes through DARPA wires, or FCC waves, it's traceable. There are ways to obfuscate. But never completely like an 'air-gapped', transaction wherein I hand a cashier $5 in exchange for ice cream.

I'm clearly in the 'it's nobody's business except for the parties involved' party...


'Cashless' as in 'cash is illegal' terrifies me. It's nothing more than a force multiplier for the power brokers (banks, govs, etc.).

There will always be corruption, theft, etc. But in one scenario, anyone can do it. In another, only the third (one) party can do it. Tell me which is better, oh starry-eyed Valley dreamer?

Its virtually untraceable. There are ways to find out if the note was new and released by the bank only to that person etc.

Which is why the tinfoil me gets change before doing tinfoil purchases xD

That's why you always get a receipt when you pay in cash - it serves as proof that you paid.

You should be living in some other universe. Most of the corruption stems from the fact that cash transaction history can be spoofed easily. There is no way to link cash with your identity linked to the tax systems. With digital payment, all the payments to/from will be linked to a taxable entity.

True enough, but this wasn't in the context of taxes - it was about avoiding getting ripped of by paying cash then having an entity claim you never paid them. Receipts are still good for this - signed receipts even better.

I've always wondered about the "don't send cash through the mail" thing. How do corrupt postal workers detect cash inside a birthday card?

Transfer convenience justice for all!

I would say that a lot of countries in EU are ahead of US in eliminating cash as well (wether this is good or bad can be discussed). The new EU Payment Service Directive 2 (PSD2) will essentially force EU banks to open apis for account information and payments to third parties.

Do you think it is good (or an "advancement") to eliminate cash?

"ahead of the West"

Ahem, ahead of the US, really. Canada and the EU can be cashless already, with chip cards and direct bank withdrawal at the POS a reality for 99.99% of merchants.

China is cashless. Stores don't accept your cash much. And you have to show a government id to buy anything. And they track you.

But it gets worse than that. If the government wants to punish you, they can just cut you off. Can't buy food, can't pay rent.

Oh you think your friends can help you? China has that covered too, with its shiny new credit system. Being associated with - let alone helping - people cut off from buying food may result in a drastic lowering of score and ability to do business yourself.

On the bright side, used wisely such coersion may he better than outright violence at stopping criminals and terrorists.

That's not accurate. I was just in Chengdu and Shenzhen last month and paid almost exclusively in cash everywhere I went. In fact for smaller vendors and street food, cash is the only option. Many vendors also accept WeChat payments (which seems to be the most common form of payment, at least for casual to mid-range transactions by people in my peer group), and UnionPay network credit cards are also widely accepted. Western credit/debit cards tend to work only at more upscale/modern/larger vendors. From what I've seen of Chinese commerce in various cities, I would be very very surprised if China went anywhere near cashless anytime soon. Cash seems to be a bigger part of the culture there than in the USA.

You do have to show government ID to get a cell phone or purchase long-distance train tickets. Also checking into a higher end hotel. And since using public Wi-Fi requires you to authenticate with your Chinese phone number, that's also effectively linked to your ID. There are many aspects of Chinese society that are easily trackable by the government, but commerce does not seem to be one of them, at least from what I've seen.

Thanks for the personal experience! So my impression was wrong. I'm happy about that.

Wait, is China really cashless now? A coworker of mine was just telling me that he used go with the accountant at his workplace to withdraw millions of dollars in cash from the bank to pay all the employees in cash. He hasn't worked in China for at least over 10 years but I didn't expect a change from million dollar cash transactions being commonplace to cashless in that time.

I dont think he knows what he is talking about. I spent 3 weeks in China in February, and used cash for pretty much everything including accommodation. Admittedly, there are lots of options for paying for things with wechat, etc. but it was nowhere near cashless.

China is nowhere near cashless. Though, they do do a lot of payments by mobile apps like Alipay and WeChat. I was there for 3 months recently and I used Alipay for almost every cos Im from NZ and whilst we have cash here I never use it, every transaction is done via debit card. Was so good when I got Alipay in China cos I hate cash. Still... China definitely isnt cashless.

Thankfully, there is a good amount of space between money under mattresses and a government controlled economy. Your comment is a giant straw man. Canadian and EU systems are private ones and the government has little or no power to directly intervene, short of law enforcement.

The idea that eliminating paper is some sort of boogeyman from Revelations is about as silly as the idea that holding on to your Glock allows you defend your rights against a corrupt government. Neither actually offer any type of protection against these particular issues.

Unless you are wandering around with $20K in cash everyday, your bank account is still subject to the very things you seem to be afraid of. The only thing that changes in a mostly cashless society is your access to your bank account. If the government is going to freeze your account, it matters little if you have a chip card or need to go to the teller.

Thankfully, we in the west have moved most of the management of this to the private sector, and require things like warrants before any real action is done. That can and is an issue at times, but has little effect on the day to day implementation of one method over another.

Sadly, I think the solution in the US and some parts of the EU is even worse than the chinese one.

Try buying Cuban cigars without cash anywhere. Your VISA or MasterCard will mysteriously fail to allow this purchase – because, due to the embargo, these companies just refuse to allow transactions containing the words "cuba", "iran", etc.

VISA and MasterCard also have additional rules of their own, and if you have a society that is cashless, they can just cut you off, too.

This is giving a for-profit entity (which, by its own nature, does not care about you, just about taking your money) far too much power.

Sweden is having that problem: You can’t do anything without a debit card anymore, banks have high fees just to get cash from your account, but the only debit cards you can get are from VISA or MasterCard.

This wouldn’t be an issue if there were many competitors, or even local competitors, or if the systems were open.

I'm Canadian, so not only can I buy Cuban cigars, I can buy them in a store down the street with my debit card. (A real debit card that connects directly to my account, not just a prepaid credit card.) Regardless though, making an illegal purchase isn't a very good reason to argue for cash; in fact you may have more luck changing the dumb laws if people are truly hurt by them.

The US definition of a "debit card" is massively different than the Canadian one. For us, our bank card is the debit card. The same one I use to take money out of my account at an ATM is the same one I can use to buy a $1 coffee.

Why some banks do charge outrageous fees, thanks to the free market there is a healthy market and many banks in Canada are now fully virtual or offer next to no fees.

Just because a system is poorly designed in one locale does not mean the idea itself is flawed, just that it should be implemented in an improved way.

> The US definition of a "debit card" is massively different than the Canadian one. For us, our bank card is the debit card. The same one I use to take money out of my account at an ATM is the same one I can use to buy a $1 coffee.

I keep seeing this pop up, but it's a misconception; we have these in the US too. I have one, although I don't use it for purchases (I use a rewards credit card that gets paid off monthly instead). Here's an example (hopefully Wells Fargo doesn't redirect you because you're in Canada): https://welcome.wf.com/checking/?gclid=CIzL2ong1NMCFVBtfgodb...

It's not that they don't exist, it's that you don't have the POS being widespread enough to support it in a common way.

The Interac system in Canada is pretty much a given for any vendor that has a cash register. That automatically makes every single bank card into a direct debit card. You can choose to use it if you want of course, but it's default for all bank accounts, really.

This is still very wrong. US debit cards work with any credit card-accepting POS. If you can enter 16 digits and expiration date and get a charge, your debit card will deduct that amount from your checking account for you.

> in fact you may have more luck changing the dumb laws if people are truly hurt by them.

But that’s the point.

Cuban Cigars are legal in Germany.

You can legally buy them.

But every payment processor that’s located in the US can not process such a transaction.

Relying on foreign companies for most basic needs means you lose a lot of sovereignty.

Given that I've personally bought Cuban cigars with my Amex card last Christmas as gifts, I'm pretty sure your assertion is false.

It's more likely the case that an American credit card holder cannot buy them, even when he is in Germany, because he's subject to American laws, as I would be if I took a box into the US and started selling them.

No, my assertion is pretty much right.

It went so far that PayPal, VISA and MasterCard ended up threatening several German store chains to stop selling products from Cuba or they’d end all business with the store

It went into national media, and was discussed on reddit: https://www.reddit.com/r/technology/comments/ka26b/paypal_bl...

Rossmann won against PayPal in court, to this date they don’t offer any payment via PayPal.

They came to an agreement with VISA and MasterCard, where if a sale contains embargoed products, everything but these products can be paid by card, but the embargoed products can not.

Processors don't send l3 data for normal consumer based transactions. How would they know you were buying cuban cigars?

> many banks in Canada are now fully virtual or offer next to no fees.

Uhh, which ones? Free chequing accounts have transaction fees for Interac, and with unlimited Interac accounts you pay monthly or must keep a minimum balance. I'm sure there are a couple exceptions, but certainly not with TD, CIBC, NBC, etc.

Check out credit unions. I'm with Coast Capital and pay zero for fees at regular bank machines. "Private" atm fees do cost, yes. Tangerine and PC financial also offer no fee options too, but I'm not sure to what extent.

Were there any facts in your answer? Where did the parent mention Revelations?

I'm not sure what you are looking for. OP linked a cashless society to being the cause of government control. This is false. Government can exert control already in a cash-based society to a sufficient degree. It's more a style of the government in question than the tech used.

You missed the part where I said a government id is required to make a purchase, so there is a single point of failure aka disconnection. This is not true in the USA or other countries where you can have cards from many different banks so if one blocks you, you pay with another. And cash certainly represents a way of paying with no such restrictions.

Acknowledge that not using cash places is "advanced" but also want to say that being able to use cash is not necessarily a bad thing. Cash allows for anonymity, allows for the un-banked to conduct their business, and prevents 100% leverage of your transactions data (not to mention transaction fees) by the companies that handle them.

You are correct in all of this, of course, but cash can always be kept for backup even in societies that are mostly cashless.

The issue of "un banked" can be distinctly American too, actually. Given the extent of social programs in Can/EU, even the nearly homeless have bank accounts, because government funds are pushed directly into accounts, and it's more secure/timely than receiving a physical cheque. Not having a simply checking account is a very rare thing in Canada.

I believe you're referring to Kenya and Ghana instead. It's called mobile money and the Telcos are actually taking a huge bite out of the banking market share

Do you know of the sorts of benefits it has brought in those places?

There's lots of people from Zimbabwe, Malawi, Mozambique etc. who come to South Africa because they can make more money here. Then they send the money back home. But if they send cash back it gets stolen 90% of the time. If they transfer the money it from one bank account to another, they don't lose their money.

Making transactions more customizeable/automated is a great advantage. Why would you not want that? Also, this just came out, so it remains to be seen what long term effects it may have.

> Then they send the money back home. But if they send cash back it gets stolen 90% of the time. If they transfer the money it from one bank account to another, they don't lose their money. Making transactions more customizeable/

WTF are you talking about? No one[1] uses bank transfers to send money to their families in the SADC region: it's quicker and cheaper to use formal and informal money transfer agencies where the recipient gets cash, which is not stolen "90% of the time".

I swear HN seems knowledgeable on all subjects except those I am deeply familiar with...

1. SWIFT transfers do get used for big transactions or paying corporations, but no one I know will be sending amounts less than monthly income this way

> I swear HN seems knowledgeable on all subjects except those I am deeply familiar with...

You can make a fairly valid extrapolation about the other areas where HN seems knowledgeable from this data point.

> I swear HN seems knowledgeable on all subjects except those I am deeply familiar with...

I started discounting what I read here about when I realized that.

Yes you are correct.

When I said, "transfer the money from one bank account to another", I actually meant not sending the money physically, but by using various other means. I didn't know how to word this, and it came out wrong.

And I was talking about the cash being stolen 90% of the time, if you do choose to physically carry it with you back home. (Or trust someone else to do it)

> And I was talking about the cash being stolen 90% of the time, if you do choose to physically carry it with you back home. (Or trust someone else to do it)

This is also not true. 17,000 Zimbabweans[1] travel into South Africa daily by road, most are destined for Musina (nearest South African town to the border) where they buy goods with cash[2]. If theft rate is 90%, that would result in 15,300 cases of theft per day (5.5 million per year) which (a) just can't go unreported, even if you think Zimbabwe is some undeveloped backwater and (b) where do I sign up to join this very effective Thieves Guild? It has to be well-paying.

1. As of 2015, numbers are seasonal. http://www.702.co.za/articles/10509/31-000-people-cross-bord...

2. Because of depleted nostro accounts, most Zimbabwean banks have a maximum international withdrawal of $20-$50 (US dollars) per day

>I swear HN seems knowledgeable on all subjects except those I am deeply familiar with..

Good old Gell-Mann amnesia.

> Making transactions more customizeable/automated is a great advantage. Why would you not want that? Also, this just came out, so it remains to be seen what long term effects it may have.

I fully agree.

Absolutely -- the police can be very corrupt in Zimbabwe so you don't want hard cash hanging around or it will be taken.

The actually official Zimbabwe currency can't really be taken seriously because of insane inflation rates.

US Dollars vary greatly in price. Small transaction fees are nothing to operate cashlessly for some of these people compare to the risk of trying to store cash.

Even India recently banned high denomination notes because they were so associated with drugs and illegal behaviour.

Actual Zimbabwean here: you are so wrong I'll have to ask: have you ever been to Zimbabwe?

> Absolutely -- the police can be very corrupt in Zimbabwe so you don't want hard cash hanging around or it will be taken.

Yes, the police are corrupt but they won't rob you[1], they might try and coerce a bribe.

> The actually official Zimbabwe currency can't really be taken seriously because of insane inflation rates.

This is wrong. It has been wrong for close to a decade because Zimbabwe "demonetized" its currency (Zimbabwean dollar) in 2008 after an infamous bout of hyperinflation - you might have seen/heard of the 100 Trillion dollar note.

1. Unless you have been incapacitated by a traffic accident. A worrying trend has emerged in recent years where passers-by or attending police go through the car and belongings of dead/dying accident victims. See http://www.chronicle.co.zw/chiriseri-corpse-robber-cop-dies-...

Is there really much practical difference between a police officer demanding a bribe and being robbed?

(I've never been to Zimbabwe: if there is a difference between cops "coercing" a bribe and what I'm assuming you mean I'd appreciate the clarification!)

> Is there really much practical difference between a police officer demanding a bribe and being robbed?

Yes: you can say no to coercion but you have no choice when you are being robbed.

Violence (or the threat of it) is a hallmark of robbery: Zimbabwean police will not do that at traffic stops - they are usually not armed. They will, however threaten to impound your vehicle for minor infractions (which would be illegal in most cases) and/or threaten to jail you to wait for your court date. Either of these situations will require paperwork and the money goes to the state and not their pockets, so they make you wait and reconsider the bribe, but eventually let you go. Usually.

Also, in the context of this thread, having cash or money in the bank makes no difference because traffic stops now have portable card machines for "spot fines"!

Analog? No. Even though they might not be smart phones, they must still be digital.

Yes, this programmable credit card for developers is exactly what the low-tech, third-world is looking for.

When can I have direct control of recurring payments? I want to be able to "push" money instead of having it "pulled" from my account.

This is a totally reasonable feature. If a merchant wants assurance that they will be paid, they should charge a deposit.

The closest I've had is Entropay, but I don't really trust them for large payments.

Recurring payments are so abused, I can't count how many times I have been mislead. And there is a strong financial incentive to mislead people. And having to contact my credit card company after the fact is not good enough.

I wish I could just have the ability to create virtual credit card numbers. I would be able to fill it with a certain balance, set up recurring balance refills, change the expiration date, keep a merchant whitelist, and cancel the number at any time. This gives me the opportunity to make sure that even if my card number was stolen or abused, the charge won't go through. If I sign up for a free trial or a service I only want for x months but need a card on record, I give them a virtual number and set the card up to cancel itself after the period is up. Or if I want to put all my netflix, hulu, pandora, etc charges on one number, I can set a monthly allowance for each merchant. If someone changes their prices, the charge gets declined and I can go back and reup the limit if I want.

I use entropay.com, which lets you create virtual credit cards, and pre-charge them. And if the account runs out of money, the transaction is declined, and the merchant has no way to get your money after that.

As a warning, there are some problems with entropay.com though. Over the last year, some merchants have been able to detect that entropay.com virtual credit cards are prepaid, and require a plastic card. Also, entropy cards are from Malta, so companies like Spotify or Netflix will only give you access to content licensed there. Finally, and most importantly, entropay.com has a tendency to "float" your money, and I've heard that sometimes they just snatch it. I've never dealt with more than $150 at a time.

Since they are based in Malta, I think it would be very hard to dispute anything with them. But if you have to do any bigger transactions, you should use a bank here anyway. But it's great for trying out services where you don't trust them, or are just concerned with overages. I use them as a buffer for a lot of recurring payments.

I've seen some services on hackernews that offer virtual credit cards, but the problem is, that they all are tied to some underlying checking account, and even if the prepaid balance is declined, the company is obligated to somehow collect the money, if they can. There's no way to simply cancel a recurring payment. I'm sure that this is because they are required to by banks in the US.

I really wanted to have a complex money firewall, like you describe, but in practice, I've ended up just using plain old credit cards for most things. It is still very good to have an entropay account, though.

Netflix gives access to content based on the country you (or rather your IP) are physically present in.

Check out privacy.com

Privacy.com is awesome! I use it for most all of my transactions which I can't use PayPal for.

Still allows through recurring payments though

In Portugal we can do just that with MBNet :D https://www.mbnet.pt/

Hey (founder of Root here), our platform gives you full API access to, for instance, do any of the things you do on the normal banking interface through code - like initiating a transfer to someone else, or building your own recurring payments system using a simple cron job :)

Apps that let you manage video game currency often give you so much more control than your bank's app gives you over your real money in your checking account! It's an imbalanced situation, and I think there's a lot of room to improve. Perhaps I can use your API to do something like that.

The banking game, gg no re.

I believe what apostacy meant was the ability to prevent a recurring payment from occurring without approval. I may have misunderstood what they meant but something along the lines of: a debit shows up in your account as pending, and you have X amount of time to approve or decline it. That way you are preventing a debit from even occurring in the first place, rather than having to fight your bank to get the money back.

What I basically want, is to have more control. I want a similar amount of control as to what I have with paper money, or even virtual in game currencies.

Right now, the scale is not tipped in my favor. I would be happy to pay for it.

I understand that banks have reasons for things to be arraigned the way they are.

I would love to have a "personal firewall" level of control over my money. I'd like to see that Widget of the month club is requesting $50, and I can confirm/deny it.

I only signed up for a widget of the month because it seemed like a good idea, but they deceived me into thinking I could back out at any time, and then when I cancelled my account, they just "paused" it for three months.

We don't use the "banking" model for other resources that are supposed to be our property. An app on my phone isn't supposed to be able to delete my photos, and the accepted solution is not that I call some external entity to undelete them. I know that these examples are very different, but that is what I would like.

I can also simply block someone from contacting me if I want, without having to justify it to my isp. I want to be able to do that with my money. If someone disagrees with me doing this, and thinks I still owe them money, they can be free to sue me, or do some other sanctions.

Right now, I create virtual credit cards and only fund them enough to pay my recurring payments. I want to automate it.

95% of the time, recurring payments that fail for me are done in bad faith, and these actors will not make a fuss if they can't process their payments.

I know this is probably a pipe dream, and that there are already system I can use, and that our financial system is set up the way it is for reasons. But that's a pain point for me, and a lot of people. People would like to be empowered, and feel that they have control. I think, in the end, things won't really change. Most people will still pay legitimate charges.

This screenshot from the front page seems to be offering something like what you want? [1] And they clearly support virtual cards so why wouldn't automating that work through their API? [2]

[1] https://root.co.za/images/rootcode.svg

[2] https://root.co.za/images/mobile-desktop-mockup.jpg

EDITS: added 2nd part and formatting

What I've found, is that every virtual credit card provider has to try to process recurring payments, even if that virtual credit card is depleted, kind of defeating a big use of virtual credit cards. I am sure that this is something they were obligated to do by other financial institutions. So virtual credit cards just end up being solely for online transactions that are not recurring.

The only company I have found that actually does what I'm describing is entropay.com, and they are based in Malta and I don't trust them for big transactions, as they have been known to steal people's money.

True, although I wonder whether the transaction can be asynchronous. For example, if you don't approve or deny within a few seconds, I'd be willing to bet that the transaction times out.

This would be fine for in-person transactions, where you can approve it on your phone, but for transactions you aren't expecting (e.g. recurring monthly subscriptions) it seems like you'd need some notice -- or a long timeout period.

I'd love to collapse all of my recurring payments into a monthly report, that I can review and authorize. This is exactly the thing banks are suited to handle.

It would also be cool if a bank could abstract bill payments for me, where they present the debit, and show the time window to pay it, and let me select what business day to process it on.

Actually, all of these services exist in one form or another. If you have a business account. And most banks have bill payment processing. But I'm surprised that no bank is offering these services bundled together, directly to consumers. I'd happily pay for a checking account console.

> I'd love to collapse all of my recurring payments into a monthly report, that I can review and authorize.

Yes, even just a list of the recurring payments (that is updated in realtime and that you can centrally discontinue) should be available to the banking consumer -- and it should be the responsibility of the banking entity to provide this feature.

The do not, because the financial sector makes its revenue from payments occurring, rather than not. A consumer would naturally gravitate towards a bank that was not limited by this concern (or derived equivalent profit elsewhere for provision of value)

I will check it out.

I would love to be able to script my bank. Chase.com is an ongoing battle. There are plenty of projects to automate banking, but it's an uphill battle.

I'm sure if I had a business account, I'd have more access than what the browser gives me.

I would love to be able to do things like, see what payments are flagged as recurring, and group them together, and sum them.

Exactly. I always imagined a future where there would be an oAuth scopes like gateway for banks. Something like -

This website requires the following permission:

    [x] Monthly recurring payments of $20
        [o] Automatically get the payments
        [ ] Send me the link to deposit every month

    > Proceed
    > Cancel
Life would have been so simpler then (Obviously I haven't thought this through completely, but something similar to this with proper security would be far superior than our current model of Name + Credit card number + CVV).

Well, this is a thing in the EU.

You usually pay via SEPA recurring transfers, and just authorize a company to take $n money monthly (and can easily revoke).

Or you set up an automated recurring transaction to transmit that much money.

Or you allow a company to take just any amount, at any time, but you can revoke each transfer.

This last is how you usually connect debit cards, credit cards, Amazon, PayPal, to your account.

I developed a serious allergy to what were called "debit orders" when I used to live outside the USA many years ago. You would sign a form to allow the merchant to debit your bank account every month for (say) a subscription.

Cancellation was theoretically possible by calling or mailing the merchant, but too many times, an extra payment (or two, or three...) went through and it was hell to get the money back. The banks were not much help - you would have to try to get the debit reversed, and it was no fun.

I think I had a few similar experiences here in the USA, but I can't recall specifics. Now I pay everything in "push" mode via online banking, as silly as that may seem.

I hope things like SEPA work better at revocation than what I experienced back in the day!

In the UK this is known as a "standing order". The account holder is fully in control of how much money goes out and when. Is this not the case in other places?

In South Africa we have stop orders and debit orders. Stop orders are for an amount agreed in advance. Debit orders allow the payee to debit your account for whatever amount they choose, obviously with the proviso that they have to produce evidence that you agreed to this, and that they can justify the charge. I've heard some stories about people having issues with unscrupulous payees abusing this, but I believe that's rare. I, for example, pay for my mortgage, credit card, cellphone, satellite TV, etc. via debit order.

Great idea. I hate the current system where companies can get access to your bank account and pull money out at will.

I think most bank's, websites already allow for this. Look under payees or pay bills

In my experience, this is only the case if you set up the payment through the bank's automatic payment system, which typically uses paper checks (but may do an electronic deposit for some payees who have specially registered).

Most subscription-based businesses that go to your bank account get an authorization to do an "ACH pull". In some instances, this authorization alone can act as collateral (e.g., in securing payday loans or medical payment agreements). As such, I would assume that allowing consumers to revoke the authorization is more problematic than it sounds.

That's right, the banks often send paper checks. Automatic bill pay is shit.

I love the concept of this... it took me a minute to figure out how I could get the most out of it, but the possibilities are endless... the fact that I can write my own rules that can manage my account semi-autonomously for me and know that my code is always watching my back even when I'm not - which is most of the time is awesome. I can have this account do everything I call the bank to get them to do and be told there's no facility for that. Things like automatically taking the remainder of my chequing account balance and dumping it into my savings account as my pay is being deposited so my account starts fresh from 0.00 each month and all surpluses are put into savings accounts. I can then have some kind of AI monitoring investments and automatically transferring money in and out of my investment accounts and TFSA... I love love love this idea. It could almost become a pension manager.

What I don't love is the lack of information they have on their website. They're in South Africa, does this mean the service is only available for South African residents and Rands? Or can we get international accounts for U.S. and Canadian dollars and more?

Anyone have any further info other than what the site presents? Do we have any founders or insiders reading that can enlighten us further?

Yes on the ProductHunt page they mention it'll be only available for South African residents as a start. https://www.producthunt.com/posts/root-6

Thanks, that's too bad

Founder here :) Feel free to ask me any questions

First, good luck - it's a difficult space and I applaud you for trying something different. I have a few uncorrelated questions:

1) Is the API limited to types of transactions or do you host configuration information? For example, I've often wished for a bank account that would look at my outgoings and some criteria that I've set, and then allocate some monies to savings or investments on a percentage basis rather than an absolute number. Are those calculations something I'd need to do at my end and then send you a bunch of API calls to make the transaction, or would they run as bots on your server? Sorry if that's not very clear

2) Will you impose tight or narrow restrictions on who can open accounts? For example in the USA many banks require an SSN to open an account and won't accept an ITIN (another kind of tax ID sometimes issued to immigrants), placing millions of people outside the banking system and thus making it that much more difficult for them to pay bills etc.

3) Will your service have access to the SWIFT network for international transfers or are you subject to restrictions while you prove some sort of banking bona fides? I don't know anything about banking relationships in South Africa or so but I've noticed the US is very aggressive about limiting transaction access for anything that looks like it could be remotely connected to crime of any kind, and I have sometimes had the impression that US banks are very 'suspicious' of anything that might coincidentally pose a threat to their business model.

I want to wish you a lot of luck and am very excited to see where this might go. I've never enjoyed dealing with money or finance, and get no more enjoyment out of being paid than I do out of paying bills. Financial chores are about as much fun as cleaning a toilet and the idea of being able to reduce the amount of time spent on dealing with money without putting myself at financial risk sounds heavenly.

Thanks :)

(1) A mixture of the two. We do allow you to write code that we host for you, to make prototyping (or building small features) easier and quicker, and you can access it all through the API, so you could do everything through a few https calls. (All account transactions are available to you)

(2) We try our best to make everything as seamless as possible, but we still have to comply with local regulations. We're working hard to create the best user experience possible given the tightly controlled environment we're in.

(3) That's part of the plan, yes :)

Hey - I previously worked on a prepaid debit platform that worked slightly farther from the metal here (post-processor).

I'm interested in two pieces of data we couldn't get there, but that I had really high hopes for.

1) Dynamic merchant-type filtering before auth. For example, if tom has spent 50$ on food this month, all merchants that identify as "food" will fail auth on further transaction attempts. I'm not sure if these are still called MCCs outside of the US, or "merchant codes".

2) Level 3/line item receipt data. For example, instead of showing I spent 5.00 at QuikEMart, it shows 2.50 on soda, 2.00 candy bar, 0.50 tax.

Will your platform offer that level of control/visibility?

Hey RickS, they are still called MCCs :) (2) is a bit more tricky to get our hands on, at least in South Africa

Cool - is MCC identifiable as part of the auth process, in the way my parent comment describes (conditional auth based on MCC)

Yeah, MCC and a bunch of other information on the merchant (name, location, etc)

I haven't seen any stack information yet (although I haven't checked the slack channel) what technologies are involved and how do you plan on mitigating the mass loads?

- for the stack was there specific criteria why certain languages where chosen in your use cases?

are there any API rate limits for clients?

are there any current plans on mitigating DDOS or other malicious attacks?

2016 has been a hard year for banks and hacking specifically the story about Bangladesh. The trend seems that this will become more likely as we move towards a full online infrastructure. For banking this is another layer where vulnerabilities can come up are there are plans in place for this?

> 2016 has been a hard year for banks and hacking specifically the story about Bangladesh. The trend seems that this will become more likely as we move towards a full online infrastructure. For banking this is another layer where vulnerabilities can come up are there are plans in place for this?

I'm not affiliated with Root, but the bank they are partnering with (Standard Bank of South Africa) was also hacked in 2016 and defrauded of R300 million ($16 million) via withdrawals from ATMs in Japan[1]. I'm sure they are acutely aware of the need for security.

1. http://city-press.news24.com/Business/standard-bank-r300m-fr...

Planning on going for corporate cards first? They'd eat this up -- directly enforce expense rules at the card. Maybe look for a buyout by concur :-)

Separately, looking to make this a platform for other vendors to issue cards? E.g., so another company can add logic for say, a teenager's card that the parents manage, and use your platform for this?

Shoutout from Canada! There are 32M of us, 88% of whom have internet. Our banks are archaic and expensive, and as a people, we have a low tolerance for that. My current bank actually believes that the telephony system is secure, compared to email :/

Our banking laws are favorable to startups; I could start my own bank, if I wanted to, for little more than the cost of a business license. Many merchants run their own little micro-banks, partly because of the aforementioned problem. Please help :)

- Do you have programmable international wire transfers in the works? That would be an instant sell to me. My current bank requires me to show up in person, and then verify the transfer by phone, both of which require making time out of a busy schedule.

- Do you have programmable virtual credit card numbers?

- Have you considered virtual bank account numbers as well? For example, I have had issues with organizations continuing to deduct from my account via ACH after stopping service. If I had a virtual bank account number that could be deleted, those rascals could be stopped in their tracks the moment I make the call saying "you are no longer authorized to deduct from my account". With the current system banks still let the unauthorized ACH transactions slide.

> Do you have programmable virtual credit card numbers?

Marqueta can do this. You can issue CC's via api, and then fund them with Visa direct. It's amazing.


Yeah, we are working on these types of things :)

> Do you have programmable international wire transfers in the works?

Unless things have changed recently, please watch out for the money laundering laws if you are in the USA. It is easier than you might think for absolutely innocent people to fall foul of them, making life miserable (speaking from experience).


In which jurisdictions will this account be available? Just South Africa?

How far inside the bank do you APIs go? Do they deploy code you wrote or how are they providing the access? Did you build on top of some raw APIs? The hardest part of this businesses is probably that connection with the bank and I'm curious about what info you can share regarding that.

1) Is there any way to get the itemized receipt as part of the event information? (I don't even know if that's sent by the credit card widgets...)

2) What are your plans for supporting other languages? (cough Ruby cough)

3) How would I make a script integrate with a 3rd service?

Hi RangerScience, the APIs are based on REST, so any language that can handle https are supported. We're also working on libraries for a bunch of popular languages :)

I would like to volunteer writing bindings for Python.

I would like to volunteer writing binding for as many languages as you can come up with, but I can't guarantee I won't shave off a fraction of a cent in transactions. Or that I'll get the decimal placement right when dealing with that "fraction"...

In all seriousness, I would be fairly worried running someone else's code on my bank account unless it was very straightforward. Even forgoing malice and incompetence, there's plenty of "wow, that's a crazy interaction between systems that wasn't obvious" to go around.

What's the backend? How is my money secured and insured? Who actually underwrites the transactions?

The underlying banking infrastructure is provided by Standard Bank of South Africa

Does Standard Bank own a stake in Root, or do they just supply infrastructure/services?

Can this interact with FNB or ABSA accounts? Is it international? In short, what are the limits?

Also, I just want to say this is really cool. I've wanted something like this for ages.

From what I know the banking infrastructure are quite uniquely suited to each.

If I could incorporate, programmatically transfer money into a business account with as little friction or pain as possible, that would be helpful. I could then programmatically say, If billy's video got 5 likes, then transfer $50 to his account, etc... Seems like it could be a nice tool for a small digital business.

Do you have to be in South Africa for this? Or can I somehow use it in the US?

Random question but it really bugs me that FNB and I think most other South African banks still use SMS/Email based secondary authentication OTPs. Are you guys planning on using TOTP by any chance?

Hey spookyuser, yeah we do, i.e. Authy/Google Authenticator supported :)

Yay, thanks!

Just FYI: Capitec uses their mobile app for that (or you can also get a keychain with an authenticator).

Really? That's great. I didn't know that. FNB should get on it then. In general FNB seems to have 'poor' security. You can't even paste a password in when resetting or signing up. They seem to just want me to be making week passwords.

FNB also does OTP within their own mobile app.

It's not TOTP 2FA though right? I couldn't add it to authy if I wanted.

Do you charge for transactions? Is there a minimum amount for an account? Do you make money through standard banking methods?

Where does the code sit? Are you doing a callback when the authorization is triggered? How long do you wait for a response?

I'm assuming you're talking about RootCode? It's in a different secure environment (detached from our other systems) and unique to each user. The execution time is limited by the POS (point of sale) devices and varies

Would you describe your business model?

Any plans to back this with a blockchain of any kind?

There is essentially no point to using a blockchain if the only thing you're putting on it is an accounting system you have absolute control over anyway.

I think tech people vulnerable to buzzwordism have an instinctive response to respond to any mention of money with "blockchain!", even though it's really only useful in this context for decentralized payment systems (i.e. not for banks). The only place banks might want to use blockchains is for low-trust inter-bank settlement.

"Absolute control" would imply I can import javascript modules and interface with blockchains directly, so you're right that it wouldn't be Root's job to utilize the blockchain if I have this ability. There is nothing to indicate this is the case, however.

edit: if it is the case, I would be excited to see some docs

We're currently playing in the fiat currency space, but we are keeping an eye out for ways to merge the two

One beta user built a script that sells bitcoin in real-time as he swipes his card and tops up his fiat account, effectively making his card "spend bitcoin" :)

As far as the US IRS is concerned, every time he makes a purchase with bitcoin, it is a taxable event where he must declare any gains/loss from the time he purchased the bitcoin. This type of regulation is hindering BTC adoption in the US. BTC also doesn't solve any problems the average person has in a developed country, but that is another story..

that's so cool. have they open sourced this yet?

There is also this BTC debit card available, which could probably be used in conjunction with your service. https://www.shiftpayments.com/card

I'm curious, to what end?

As an extension to customizing your bank account. It'd be nice to be able to pull funds from cryptocoin accounts or make calls to smart contracts, etc. I'm thinking this could be the IFTTT of bank accounts, so I want to see as many connections as possible.

Well that makes sense, but not what I would call "backing it". I think the terminology confused me, integrating other accounts, etc. is a clearer target.

How many 'virtual' cards can a user have?

> 1337 1337 1337 1337 Erlich Bachman

Seems legit. Also, I hope that CC number on your top background image is flagged to never be handed out to a real customer ;)

Otherwise this looks promising. I hope to see something like this in the USA soon!

As another person suggested on this thread, I want to program my own fraudulent activity check. E.g. if someone buys something x miles from where I live.

Would that be possible with your API?

Your page shows a sample bit of code (the beforeTransaction function) that approves a transaction. Does MasterCard (or whoever) still run their approval magic before that?

What do you mean by their "approval magic"? There are other fraud filters etc built into various places throughout the payments system.

I think parent is referring to 3-D Secure (3DS). This is basically an authentication step which delegates most of its implementation to your bank (or whoever your credit card provider is).

I'm not sure what Standard Bank is doing with regards to 3DS, but it would certainly be neat if its implementation were programmable as well.

Yes, this more or less.

Did you guys write your own debit/credit card processor?

Is this usable in the United States?

On your main page you have two images of your card, probably worth making them the same.

Please come to Canada! I will cry of joy if this becomes available up here.

I'd like to have something like this for Germany. I am willing to pay 10€/month for a simple API access to my bank account. I need neither hosted code nor push. Just give me remote access for my scripts.

Probably I'm asking for the impossible because of the heavy regulation in Germany but just wanted to put it out there.

N26 has got a quite decent REST API if you are willing to use your dev tools for a bit :)

Edit: Most banks also seem to support FinTS [0], but it seems a bit of a PITA.

Edit 2: figo might be worth a try as well, though I don't know their pricing.

Edit 3: bunq is quite nice as well. I implemented a few basic calls in node when they launched the API. Not the easiest API to work with, but acceptable.

[0]: https://www.hbci-zka.de/index.htm

[1]: https://www.figo.io/en/

[2]: https://www.bunq.com/de/api

[3]: https://github.com/c0dr/bunq

Don't trust them. They really fucked up there security.


No need, you can instead trust the common deposit insurance (up to 100,000 Euro)

If you watch to the end of the talk, you discover that N26 acted courteously and responsibly to the report, and all the security issues have been dealt with.

RE: N26 I think we very much disagree on what decent API choices are :) https://media.ccc.de/v/33c3-7969-shut_up_and_take_my_money

Every time I see anything about N26, I am quite disappointed that it isn't available in the US.

It is quite good, but it's not perfect. The apps look non-native and the UI has many issues (e.g. entering 10 international characters quickly in the "transfer note" box pops up 10 "only latin characters" notifications), the login UI looks weird on Firefox, and http://my.n26.com/ causes an infinite loop that I reported weeks ago.

Other than that, I'm very satisfied with the service, and I use them as my bank bank, but I use Revolut (revolut.com) for my everyday transactions, just because it "feels" nicer. The transparent N26 card definitely turns heads, though, cashiers are always asking me about that.

> The transparent N26 card definitely turns heads, though, cashiers are always asking me about that.

Weirdly enough barely anyone in Germany ever commented on it while in South Africa people do so every time I'm at a store :D

Thanks, nice list. Do you know of any aggregators in Germany that can provide a (read only) API for popular German online stock brokerage or pension fund accounts?

Rrrreeeeally? That's extremely interesting. It's not officially supported, though, is it? Still, it might be nice for various scripts.

Afaik N26 have no open API for public use.

AFAIK the best way to access German bank accounts programmatically is AqBanking, which is used by e.g. GNUCash. It also comes with a CLI: https://www.aquamaniac.de/sites/aqbanking/cli.php

Sieht gut aus! I'll give it a try, thank you.

I doubt it's even regulation, just inertia.

There used to be (still is?) an API called HBCI, but to my knowlegdge that required a smartcard (maybe not to bad an idea) and was mostly read-only. I think in the early 2000s you could use things like Quicken and MS Money to do homebanking (is this why some people in Germany still have the impression that it is dangerous and complicated?)

I think what "Sofortüberweisung.com" initially did was just to scrape the websites of all major banks, and use the HTML as an API. Then the banks found out they could not do much against it legally (and also fearing backlash because they had no good website-payment solution themselves), and they made some agreements.

It still is though it's recently called FinTS. Most german banks implement it and it's read/write usually. Every bank has some specialities (even sometimes some bank branches have specialities) so it's usually not _that_ easy to implement if you want support for all banks.

"All" banks in Germany are run by less than 10 data centers. The second biggest, Fiducia, operates about 600 banks. This is one API for 600 banks.

For the API - almost all business accounts support HBCI or EBICS. For example my tax accountant and tax software have full access to my business account.

FinTS kinda works, and there some libraries out there to make life easier, but it's still somewhat terrible. PSD2 is coming, tough, and I'm hoping it will improve the situation: https://www.evry.com/en/news/articles/psd2-the-directive-tha...

You can simulate a browser and act as if you're a normal, browser using customer. Encapsulate it and you've got an "API"; though it'll be a bit painful as a lot of banks' web backends are fucked up and you'll need to keep up to date with their changes, but still. I did it for my French bank account at one point (get balance + submit transfer).

Apparently, some used this technique for actual commercial services, which was partly motivation (they called it "screen scraping") for the European Commission's recent directive to require banks to allow authorized third-party access to customer account data.


Your comment might be the first I've seen justifying the use of Electron. ;)

Have you thought about using a headless browser or web scraping?

A friend of mine did this but after two times web access being disabled for his account because "suspicious activity" he stopped. Second time he actually tried very hard to simulate a human with delays, user-agent, browser capabilities and so on but didn't help.

This is getting harder and harder. Chrome allows you to do a .click but it also sends a tainted flag. I'm not sure if headless browses also send non-tainted events.

For spain, too. Actually I am forwarding this to a friend in a huge bank. Hope this helps :-)

I have written my own script which makes use of AqBanking-CLI. Postbank does support HBCI.

Anyone remember Seed[1], the YC startup that tried to do programmable bank accounts years ago? They did eventually launch, and I have an account, but all the programmable stuff went away and we're left with basic business bank accounts rather than the original vision.

I wonder what happened there, and I hope Root can better stay on track!

[1] https://news.ycombinator.com/item?id=9066363

Hey there. I'm Brian, the CEO of Seed. Thanks for remembering us and thank you for trying us out. :)

Long story short, we're still working on making the API available to our members. Plans changed along the way and we ended up releasing our mobile business bank account first, but our long term goal of offering a more open platform remains.

It's tough to do anything innovative within the US banking system due to regulations, partner challenges, risk, and other factors, but we're going to keep working at it.

Hey Brian, I'm glad to hear that you guys are still at it! Your original vision is exactly what I wanted. We got an account for our small business because paying contractors with a monthly cron job that initiates an ACH transfer is exactly the kind of nerdy thing we want to do. We're using it, and waiting for the API to come along.

I hope you guys succeed! Not many startup founders look at the tangled mess of regulations that is the financial sector and think, "now that's where I want to be!"

Applications are open for YC Winter 2024

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact