News for hackers. Stuff that matters.
Re:The Secret API of Banks by dddddaviddddd on Wednesday August 08, 2018 @04:14PM (#17719046)
Particularly in user-facing aspects
Re:The Secret API of Banks by lgregg on Wednesday August 08, 2018 @04:16PM (#17719061)
I just had a 45 min talk with a rep of my credit union; She agrees. They don't have per transaction alerts.
Re:The Secret API of Banks by TomMarius on Wednesday August 08, 2018 @04:28PM (#17719180)
What user facing aspects bug you the most?
Re:The Secret API of Banks by TuringNYC on Wednesday August 08, 2018 @04:39PM (#17719278)
I'd love:

- Universal, near-instantaneous per transaction alerts. It helps stop fraud right away rather than after-the-fact. It also helps solve problems while they are fresh rather than trying to resolve a month-old+ issue. Some countries overseas do this almost universally.

- On-restaurant-table credit card swipe rather than taking the card away and entering tip later. Many places overseas do this almost universally.

-- Side note on the txn alerts: I suppose it is due to the way Visa/MasterCard are processed, but I sometimes get alerts a day or more after i've done a credit card transaction. Some cards dont even have the option for alerts.

AMEX has great alters, almost instantaneous, but I suppose they control the entire stack, so that makes sense.

Re:The Secret API of Banks by cesarb on Wednesday August 08, 2018 @04:55PM (#17719395)
> On-restaurant-table credit card swipe rather than taking the card away and entering tip later. Many places overseas do this almost universally.

If they took the card away, how would you enter the card's PIN? That's why places outside the USA do the swipe on the table.

Re:The Secret API of Banks by TuringNYC on Wednesday August 08, 2018 @05:08PM (#17719501)
In the US, almost universally, they take the card away. Swipe it somewhere in the back -- without a PIN. Then bring back a receipt for an inked signature, which is supposed to the be the alternative to a PIN.

Oh, and you put the tip in on that receipt, and they go back and do a second entry of the tip (sometimes incorrectly, almost always higher when incorrect.)

Worse - the transaction alert -- if you get one -- is the pre-tip amount. Makes no sense.

Re:The Secret API of Banks by dyu on Wednesday August 08, 2018 @09:42PM (#17721105)
FYI if they enter the final amount incorrectly you can dispute the charge with your credit card provider. It's probably a stronger case if you kept your own copy with the final amount that you wrote down.
Re:The Secret API of Banks by JoshTriplett on Wednesday August 08, 2018 @04:44PM (#17719305)
> - On-restaurant-table credit card swipe rather than taking the card away and entering tip later. Many places overseas do this almost universally.

This isn't a problem you can solve by changing the banking industry. This is a point-of-sale problem.

Re:The Secret API of Banks by spookthesunset on Wednesday August 08, 2018 @04:54PM (#17719380)
> This isn't a problem you can solve by changing the banking industry. This is a point-of-sale problem.

It's all part of a larger set of "problems with US financial services". The fact that it is technically different vendors is not relevant...

Re:The Secret API of Banks by JoshTriplett on Wednesday August 08, 2018 @05:07PM (#17719481)
It is if you want to solve the problem across the board, rather than having a niche system that a small handful of vendors use that just introduces one more surprising variation at payment time.
Re:The Secret API of Banks by ceejayoz on Wednesday August 08, 2018 @06:58PM (#17720354)
I disagree entirely. The problem is that the US banking industry permits this state of affairs. They should require updated, at-table point-of-sale devices within a reasonable timeframe to be able to continue to take credit cards.
Re:The Secret API of Banks by hakfoo on Wednesday August 08, 2018 @09:26PM (#17721057)
It always seemed odd to me that the card readers are owned by the retailer. On the one hand, that leads to a lot of old or insecure-by-design equipment in circulation as 'not worth the cost to replace", and on the other hand, it tends to lead to a lot of annoying spam calls of "we'll replace your machine if you switch your payment processing to our company."

If the upstream providers provded the readers as a leased service instead-- maybe for a few dollars a month-- they could push out insecure gear in a timely manner more aggressively. Just reject connections from old devices because everyone renting the old model has been sent a new one already. It would also eliminate the price of equipment upgrades as a leverage for competitors to peel off customers.

From what I can tell, the machines are fairly locked to the service providers, and require fairly intensive setup, so it's not necessarily like an unlocked phone where you'd save money by buying a device independently of the service.

Re:The Secret API of Banks by ajdlinux on Wednesday August 08, 2018 @10:39PM (#17721327)
Not that I have practical experience with this, but I believe that equipment leasing is the norm in Australia.
Re:The Secret API of Banks by JoshTriplett on Wednesday August 08, 2018 @07:02PM (#17720385)
Migration has a cost. Many small vendors have razor-thin margins.
Re:The Secret API of Banks by ceejayoz on Wednesday August 08, 2018 @07:08PM (#17720412)
Then have the banks fund it out of the savings from reduced stolen card fraud.
Re:The Secret API of Banks by hakfoo on Wednesday August 08, 2018 @09:14PM (#17721013)
If I want to make my financial life difficult in the sake of security, that should be my choice. I'm sick of banks saying, either implicitly or outright, "we don't want to ratchet up security measures because people will find it inconvenient. You can say that because it's not your money on the line.

Why can't I ask for chip-and-pin or nothing? No chip-and-signature, no swipe-and-pin, no swipe-and-signature,no it's-less-than-$50-so-nobody-cares-and-we-don't-even-ask-that.

Why can't I have a card inactive by default-- if not used in a week, you have to press a button in the app to re-activate it before it works again? Then you could potentially add "the next charge will be $120 +/- 10. Those would make for a smaller target for spray-and-pray fraud.

Conversely, when they do try to protect you, they do a terrible job of it. My bank (one of the largest in the county) has a particular hard-on for the website of a large regional electronics retailer. In person, fine, but if you order from their site, odds are 50:50 it will fail and your card will get fraud locked. I am significantly less likely to order from them because I know it's going to be a hassle, even when I see an offer I want. If I could white-list the merchant, problem solved. If many customers whitelist them, it might provide better information for their automated anti-fraud systems.

Re:The Secret API of Banks by perl4ever on Wednesday August 08, 2018 @09:22PM (#17721046)
"I'm sick of banks saying, either implicitly or outright, "we don't want to ratchet up security measures because people will find it inconvenient. You can say that because it's not your money on the line."

But my money is not on the line. That's what a credit card is - I'm using the bank's money, and I am not charged for fraud. If the bank was seeing excessive amounts of fraud, they would ratchet up security measures.

However, any security measures should be treated with skepticism - do they measurably increase security, or do they serve merely to transfer responsibility away from the banks?

"Why can't I have a card inactive by default-"

You can get single use numbers on many cards, which I think would solve your use case.

Re:The Secret API of Banks by hakfoo on Wednesday August 08, 2018 @10:06PM (#17721215)
> But my money is not on the line.

Well, I tend to think in context of a debit card, but covering your ears and screaming "zero fraud liability" doesn't solve everything.

You're still incurring costs and hassle getting your account detangled after a fraud, and the trouble for getting the cards reissued. The bank itself is going to have to deal with the costs of insurance and payments it was unable to recover. Eventually, somehow we're paying for that in higher fees or worse rates.

It also tends to undermine the fundamental legitimacy of the bank. Remember when banks tended to be big free-standing buildings with huge visible vaults? The message was "we're keeping your money safe." Not "we don't keep it safe, but we have really awesome insurance when we inevitably mess it uo!"

Re:The Secret API of Banks by spookthesunset on Wednesday August 08, 2018 @04:53PM (#17719373)
- Instant, ultra-low cost inner-bank transfers. None of this "wait a day (or more)" ACH business or "send money via paypal, but then have to wait a day (or more) to ACH it into a real bank account". Useful for everything from paying friends back to moving money between two personal accounts.

- ubiquitous NFC-based payment systems

Re:The Secret API of Banks by jsjohnst on Wednesday August 08, 2018 @06:39PM (#17720205)
> Instant, ultra-low cost inner-bank transfers.

I assume you mean inter-bank. Many US banks do instant transfer between accounts in the same bank, even if different account holders. On the inter-bank front, there’s Zelle that many US banks support that’s instant and free, but it has stupidly low limits. On the kinda instant front (aka under 15min), wiretransfers exist but they are a poor UX universally and have a steep fee generally (my bank does it for free, but I have to have a high end account for that).

Re:The Secret API of Banks by GordonS on Wednesday August 08, 2018 @05:27PM (#17719649)
We have this in the UK with "faster payments".
Re:The Secret API of Banks by tachang on Wednesday August 08, 2018 @05:11PM (#17719520)
Banks do this so they can gain the interest on the delay. Very annoying though for the end usrr
Re:The Secret API of Banks by jsjohnst on Wednesday August 08, 2018 @06:41PM (#17720230)
That isn’t the whole story, the Federal Reserve and their antiquated process is another major factor.