Hacker News Reader

Comment by datadata | Hacker News Reader

It is fantastic that a company operating with such horrific practices is dead. While we are at it, when can we fix similar issues below with mainstream financial systems that millions of people are still using?

- Social security numbers are used as a secret for identification, despite being in plaintext and having so low entropy as to be guessable, and originally issued on a card literally saying "Not for Identification".

- Every bank check lists the bank account number, which serves as the only information needed for a party to issue a request to withdraw money from that account.

- Credit card numbers are similarly a private number used as a public number, and printed on plaintext on the card.

Is there any effort working on bringing asymmetric encryption to these systems or to replace them that has a reasonable chance of working?

View on HN

> Every bank check lists the bank account number, which serves as the only information needed for a party to issue a request to withdraw money from that account.

The same principle (i.e. knowing an account number means being able to debit it) works surprisingly well in many European countries for direct debits, and the account number is considered even less of a secret than it is in the US. For example, many freelances routinely print it on their invoices sent out to clients, have it as part of their e-mail signature, or even prominently feature it on their website.

What makes it work is that, under the SEPA Direct Debit framework, the risk of fraud and insufficient funds is 100% on the party initiating the direct debit. An accountholder can literally click a button on their bank's app or website and they get the funds back immediately, no questions asked, within 8 weeks of the original debit date.

This, in turn, means that it is in the initiating party's self-interest to only accept this form of payment in high-trust situations, and not just like a low-fee replacement for credit and debit cards that shifts some amount of fraud risk to the accountholder or their bank.

> What makes it work is that, under the SEPA Direct Debit framework, the risk of fraud and insufficient funds is 100% on the party initiating the direct debit.

It also helps that the accountholder has to allow each party that will debit money from their account. By default, those requests are denied.

AFAIK, the US works the other way around.

> AFAIK, the US works the other way around.

"Positive pay" is available for checking accounts in the US, though I've never heard of it used outside of business accounts, and only then by request (and probably extra fees).

> By default, those requests are denied.

This depends on your bank, mine allows them by default.

Which European bank is it?

> By default, those requests are denied.

That's not the case in Germany, at least.

Banks don't need a SEPA mandate to allow a direct debit?

The SEPA mandate is between the parties in the transaction. While banks require their existence, it is usually not shared with the banks involved.

So only a creditor ID is needed if someone has a set of IBANs and then things will be processed?

A creditor ID and a direct debit agreement with some bank, yes. After you have those, (usually) the banks won't verify individual transactions.

Do you mean that if I know a German bank account number I can just withdraw money for me?

Be right back, asking some German friends for their bank account numbers.

Jokes aside, you're probably wrong. There's NO way I can just pull money from their bank account just by knowing their bank account number.

As a person you can only send them money. As a business you can initiate a direct debit which withdraws money. However you are attesting that they signed a direct debit agreement with you and provided their account number and agreed on the amount to pay.

This is the same as a credit card - you can charge any card with just the number and a couple of basic details, however if there's a complaint "I found these CC details on a random website" isn't accepted, you need to show the card holder agreed to the charge. If you don't provide the evidence the transaction is reversed.

That is usually not how credit cards work anymore. Sure, you can try to charge any card but if it is issued by a European bank it will very likely be denied and you will be asked to do a Strong Customer Authentication.

Same applies to SEPA direct debit. Here in Sweden most (all?) banks requires the customer to sign digitally before any direct debit mandate is created.

That's a distinction without a difference.

I obviously don't care about people sending me money, I care about people requesting money from me.

Individuals can't do it and business can only <<ask>> for money, that's different.

Yes, if you set up a direct debit agreement with a bank you can do that. If you'd actually try what you suggest it will be revoked quickly and charges filed as your identity is known.

> Jokes aside, you're probably wrong.

What GP says is accurate.

> Do you mean that if I know a German bank account number I can just withdraw money for me?

You most likely can't, because if you have to ask this you don't have an agreement with a SEPA Direct Debit originating bank that lets you :)

And even if you decide to open one now: Given the risks involved for the originating bank, they will heavily scrutinize your business case and demand considerable collateral and/or payout time limits.

Yes, yes you can. Name + IBAN is all you need to enter even large recurring payments.

I don't believe that.

Let's say I have account number 1234 and my name is John Doe.

You're telling me that, no strings attached, no repercussion, Mike Hacker can set up a large recurring payment from my account, without my approval?

I'd need solid proof of how that would work.

Yes. That is a thing that can be done, here’s Stripe’s documentation on how to set up a Direct Debit mandate: https://stripe.com/docs/payments/payment-methods/bacs-debit?...

The thing that’s being missed here is that direct debits can be disputed in the same way a credit card payment can, and by default the customer wins. Their money will be refunded immediately by the bank, who will then go after you to get it back.

Yes and no. Swedish banks for example will just deny direct debits unless the customer has explicitly agreed to let their accounts be charged. So direct debit works differently per country and per bank.

Ok, that's both interesting, slightly unsettling, but also doesn't really fall under:

> You're telling me that, no strings attached, no repercussion

This bit:

> by default the customer wins. Their money will be refunded immediately by the bank, who will then go after you to get it back.

sounds a lot to me like repercussions :-)

Most importantly, you need a bank that will let you submit any DD requests.

This does have a minor drawback on the service provider side as allowing people to sign up for a service with direct debit is hard to get right, so many services prefer to offer credit card payment even if it is more expensive. There is no way for you to verify that a person signing up is actually the account holder save for doing the "we debited 1c on your account" thing, which takes a few days.

Yes, and that's arguably by design. If you need confirmation of funds, cardholder/accountholder authentication, and a dispute mechanism that doesn't side with the customer in 100% of scenarios, SEPA Direct Debit is probably not the payment method you want.

> the "we debited 1c on your account" thing

This doesn't actually work with SEPA Direct Debits, since there is no such thing as "disputing a reversal" or "compelling evidence": If the accountholder says "funds back, please", the involved banks have to oblige.

In fact, direct debits are so reversible/non-final that it's SOP for bankruptcy managers to claw back all of the last 8 weeks' worth of direct debits drawn on a bankrupt person's or entity's account, which can be quite surprising for debtors.

In other words, it's possibly a better mental model to think of direct debits as a request for a wire in 8 weeks that gets earmarked for approval by default if enough funds are present, but that accountholders can cancel at any point in time, as far as finality (but not liquidity) is concerned.

The main problem is that if the service provider has no proof that they legitimately had a contract signature, the account holder can reverse the transaction for much longer.

> What makes it work is that, under the SEPA Direct Debit framework, the risk of fraud and insufficient funds is 100% on the party initiating the direct debit.

Additionally, you need to have a direct debit agreement with your bank to be able to initiate a direct debit. You need to show at least some legitimate banking history (and a government-issued ID) to get one, and they come with limits on how many and how much you can debit per period, and your bank will terminate the agreement if your reversal rate is higher than normal.

At least with my bank, and I think most banks here in Sweden, I need to approve people before they can make direct debits.

How do you approve a payee with your bank? At the time you grant them permission to debit your account, or at the time of the first payment?

There is no technical channel for the former within the SEPA Direct Debit framework (i.e. the first time the payer's bank learns about a mandate is with the first direct debit), so I'm wondering if this is a different/domestic direct debit scheme.

Traditional banking is sufficiently slow enough that things can be reversed before permanently settled. The "slow" speed of moving money is a feature. It's designed for humans who make mistakes all the time.

I agree that it is a feature, but that feature didn't come with any downsides initially when the speed of everything else was also slow. The downsides are now substantial as the customer expects higher speeds. The downsides of not having the option to have final settlement quickly also seems to be a source of many other problems.

We also don't even need to change this aspect of traditional banking in order to add strong asymmetric encryption in front of the system. That would nip most fraud in the bud, and if nothing else save a lot of effort that goes into fraud schemes, prevention, and reversal.

Honestly, I don't really see this. Small personal transactions happen via Cash, Venmo, PayPal, Zelle, etc. without much issue or friction. As far as the general consumer is concerned it is instant.

Large business transactions generally (not always, obviously) do not have the sense of urgency that would require fast settlement. There's some market maker stuff that benefits from fast settlement, but that's not exactly a reason to push whole new system out to everyone.

The biggest "benefits" of crypto are not benefits to the average consumer going about their daily life. Instead of dealing with fraud you'd have to deal with customer service issues for actual customers who forgot/lost their keys. And, honestly, you'd probably have to deal with more fraud. Your phone gets hacked, your keys get stolen, and then what… all your money is irreversibly gone?

You are imagining a false dichotomy where things like fast and final settlement, or self custody are forced onto every user, and pointing out the obvious problems with that scenario. They are not good defaults, but they are great to have as options to protect customers against a fraudulent or over leveraged system. It is a bit like any protected right-- you don't have to directly make use of it for it to be valuable, the real value is in the optionality you have to be able to use it, and the risk that optionality poses to those who would exploit the absence of the right.

Not really. Fast (immutable) settlement is terrible for humans. Self custody is more or less incompatible with our modern world. And despite that, there are ways to do both without crypto—hand someone stacks of cash and keep gold in a safe under the floorboard. Both of these options exist.

You are repeating the same false dichotomy by stating again that final settlement and self custody are bad defaults for the entire world. That isn't want I'm saying, I am saying a choice is better than no choice at all. I'm also not saying anything about crypto. Gold and cash are also useful instruments that should be financial instruments for everyone also.

> The downsides are now substantial as the customer expects higher speeds.

Why would they expect this? It seems like the slowness is the only thing keeping the game from growing legs and walking away from the humans playing it.

Ask anyone waiting for an emergency withdrawal to settle from a failing institution like FTX or SVB.

On the flip side, think about all the old people that initiate transfers to various scammers and get stopped by the bank.

Making things faster will be good for some people, bad for others. Not clear if better on the whole.

It’s also probably better to keep it slow to prevent impulse decisions (let me put all of my money into dogecoin, it’s mooning now)

According to both of them that’s what sank them and not the blatant shenanigans going on.

If there were more of a delay, like the maturity rate of whatever bonds, SVB would be fully functional today.

FTX, as long as nobody looked too hard they probably could have lost the few billion they had left while keeping everyone happy.

Bank runs… always blame the customers.

Each one of these systems has a better replacement, but not all of the industry has moved to it.

The largest related issue I believe is that the use of “knowledge databases” by credit bureaus (and all of the companies and governments that trust credit bureaus).

Each of these has been solved, but until the last system using the inferior authentication is upgraded, they all remain weak points. I have argued that the US (or each state) should create a digital certificate system similar to Estonia’s “digital residency card” or S Korea’s online transaction signing (although hopefully not implemented as an ActiveX control for Internet Explorer 5).

> Estonia’s “digital residency card”

The EU is actually federating systems like that under an umbrella of regulations and technical services called eIDAS [1]. I haven't been able to use it in too many places yet, but if it takes off (which is a pretty load-bearing "if", to be clear), I think it could be an important step towards making these systems usable internationally.

Especially the US, which seems to prefer to handle ID card issuance at the state or even municipal level, could benefit from a federated approach like that – assuming that people would be willing to trust their local/state government to that extent, in any case.

[1] https://en.wikipedia.org/wiki/EIDAS

> assuming that people would be willing to trust their local/state government to that extent

We have too many religious people who fear government ID cards are the “mark of the beast”. We still can’t get all states to migrate to RealID, which includes a digital verification method within the ID (something stronger than a barcode).

This is mostly unique to the US. Where I'm from, we don't use our SSNs as passwords, bank checks and direct debit are simply not a thing, and credit cards have two-factor authentication for online purchases.

2FA for online purchases is, at least in Germany, is not always a thing. I don't know how it's decided, but I'd say only about 50% -70% of online purchases trigger the 2fa of my bank.

My understanding is that it is related to the fraud prevention capabilities (incidence?) of the other party and the amount.

It is virtually always a thing here in Sweden. The only exception I have encountered the last like 5 years is Paypal.

"While we are at it, when can we fix similar issues below with mainstream financial systems that millions of people are still using?"

The literal answer to your question is, no, probably not.

It's not that it's impossible, it's that a lot of the technical talent required for doing it at every financial institution that would need to, is deployed elsewhere (some of it in finance, but not in the improving-security part of it).

> Credit card numbers are similarly a private number used as a public number, and printed on plaintext on the card.

I have an Apple Card. The only text on the card is my name. I think a lot of bank cards are starting to do similar stuff.

It isn't foolproof, though. Someone somehow was able to charge against the card, a couple of months ago.

The lack of identifying numbers causes no end of confusion when I travel with it too, especially in European countries that Apple haven't launched the card in yet.

It got so annoying on a recent trip, I just reverted to using another conventional credit card. The Apple Card is generally fine any time I use tap to pay from the phone, but the physical card simply isn't as reliable as some other cards I have that generally "always work" abroad. I've even had restaurant staff treat me very suspiciously over the blank card.

Its also an odd card in that the physical card itself has no tap-to-pay functions at all; of course Apple want you to use the iPhone it can't operate without to do this part instead. Again though, if I do have to hand over the card, in Europe people will of course try and tap it instead of a swipe and once again confusion reigns.

Oh and if a server drops the card, it makes the most irritatingly loud clang being a small metal object - I would happily go back to plastic for the card!

I went to Europe and used Apple Card almost exclusively with zero issues. Both via Apple Pay on my iPhone as well as using the physical card. Seamless experience.

For credit cards, mobile wallet transactions are tokenized, and EMV chip transactions function similarly.

You think that is bad, every doctors office I have ever dealt with over the phone has just asked for my name, and birthdate. Think of all the friends on social media I can impersonate!

> Every bank check lists the bank account number, which serves as the only information needed for a party to issue a request to withdraw money from that account.

A check is simply a contract -- a promissory note. Like any contract you wouldn't sign it with someone you didn't trust, right?

(Obviously that statement, while true, is risable these days. But I remember a Bogart film in which he was setting a debt at a casino so asked the owner for a check -- he filled in not only the amount but his name, address and bank).

All the info on your check is just printed there as a convenience to you, or at least used to be. Until ~20 years ago physical checks were still sent back to your bank where they would check the signature, which could take a while! I think since the 72 hour rule went into place (and sending checks physically no longer allowed) the format was set by regulation

If you trusted the person from whom you accepted a check, why didn’t you simply accept a promise to be paid later?

Put elsewise, the salient feature of a check is that your trust in that bank backstops your lack of trust in the bearer of the checking account.

(Right? Or did I misunderstand your trust model perhaps?)

The check is a promise to be paid later. You are trusting the check writer that they are good for the money. The bank could refuse to honor the request if there isn’t enough money in the account or they don’t believe the document is legit (looks altered). In the not so old days* you’d have to wait for the check’s bank to accept it before you got your money.

And the writer is trusting you not to modify the check or otherwise fraudulently use the account info (in my parents’ time the check didn’t have account numbers on it so this was less of a risk).

The only backstop the bank offered was to verify the signature against the signature card and refuse the check if it looked suspicious. I think the same is still true today.

* I worked for Atari back when Warner owned them (1980s). Congress had required that companies offer direct deposit, but the minimum was they only had to offer it to you if you banked at the same bank as the company. So Atari’s payroll came out of a small bank in Sunnyvale with only one office. The rest of us got paper paychecks on Friday. Even if you went to the bank before 3 on Friday it wouldn’t be processed until Monday, which meant they’d send the physical checks to Synnyvale to be validated. Warner got to use the float on the money while all that was going on.

One brief and illuminating trip through UCC-4 and it appears you are correct. Thanks for the explanation.

Me, many years ago setting up electronic payment. -OK, it's asking me for my bank account and routing number. These must be pretty secret. -Oh wow, they're both printed on my checks. Uh...this system works?

> Every bank check lists the bank account number, which serves as the only information needed for a party to issue a request to withdraw money from that account.

Just here point out that the issue is that it's enough to have the bank account number to issue a request to withdraw money from that account, and not that the bank accounts numbers are listed.

I can't echo the general point here strongly enough.

It's tempting to make this all "about crypto."

But crypto's just a technology. Maybe it ends up being a thing, maybe it doesn't. The fundamentals remain, and one of the present fundamentals is that (along with good old fashioned grift) stupid and terrible cybersec practices run rampant still.

I mean you’re right in that, thinking about this on an abstract level, your suggestions seem like no-brainers.

But the current system works well enough in the vast majority of cases. And the fixes to the problems you list would add considerable complexity. I don’t think it’s actually that clear that fixing these problems would have a net positive effect on the world.

The size of the market just for identify theft protection is 10 billion USD [0]. There is 30 billion USD in credit card fraud a year [1]. I don't think that is working well enough, that is a multiple-FTX sized loss of money every single year going into a problem that is fueled mostly by really bad underlying security systems.

0: https://www.globenewswire.com/en/news-release/2022/03/23/240.... 1: https://www.bankrate.com/finance/credit-cards/credit-card-fr...

- Banks not doing their due diligence to make sure they are lending to the correct person, and then being allowed to blame the victim for it.

>- Social security numbers are used as a secret for identification, despite being in plaintext and having so low entropy as to be guessable, and originally issued on a card literally saying "Not for Identification".

This is by design: millions of Americans believe that the clunkiness of the SSN protects them from tyranny.

Reply on news.ycombinator.com