Plaid is only one security breach away from being utterly destroyed. And they will take out the financial lives of all their customers with them.

It’s utterly irresponsible and I have no idea how Plaid hasn’t been shut down. You have no recourse if they are breached. The TOS of your online banking probably says that if you disclose your username and password to any third party then you have no liability protections.

> It’s utterly irresponsible and I have no idea how Plaid hasn’t been shut down. You have no recourse if they are breached.

Wise (formerly TransferWise) is another example. You have to move funds into your Wise account before you can do a transfer, payment, or currency exchange. Wise offer various ways to fund your account such as wire transfer, credit card payment, debit card payment, etc., each of which has different fees, but by far the lowest fee is "direct debit" which involves giving Wise your bank card number and password. I imagine that the overwhelming majority of Wise customers have no idea that this is terrible for security and privacy.

Everything about this practice is hard to believe:

1) I doubt that any bank has given Wise permission to do this.

2) Which raises the question about why the banks aren't blocking IP addresses that Wise uses to log into bank accounts, or at least making a complaint to Wise.

3) It's obviously against the banks' terms of service, but Wise may be breaking some law regarding unauthorized access (in the same vein that you can't authorize a third party to use your passport, for example).

4) What else is Wise doing after they log into your bank account? Are they collecting other information about your transactions and balance?

5) Does Wise store your bank card number and password? If they do, they'd have to store it as cleartext (not as a one-way hash) if they expect to use it again. They could encrypt it of course, but it would have to be reversible so they could get the cleartext back.

6) Why hasn't any bank regulator forced them to stop doing this?

I've never seen this in either the UK or Finland when using Wise. Direct Debit is a legit thing that's more common in the UK - but that takes several days to clear and the protection is quite strong, Wise would have lost a lot of money to fraud if they offered it as an option...

They use Trustly in the Nordics to do something similar to what you mention, which does seem to use propper bank APIs - as I have to authenticate it on the bank app or website separately.

I just transferred some cash from UK -> Europe and whatd'ya konw? There is indeed a hook to the bank, but I am pretty convinced that it is just the legit, real, EU (& UK) wide open banking that Wise have implemented for most of the popular UK banks, mainly because I was on the First Direct (my bank) site the entire time once I clicked through, and I still had to authenticate properly with the app for anything to actually happen.

Are you sure you're not confusing things? Direct debit usually means just a permission to charge the given account for the specified amount. It's commonly used in Canada and doesn't involve sharing your password.

Wise (formerly TransferWise) has different meanings for "debit" and "direct debit".

Their "debit" option works the way you think. You give only your bank card number, expiry date, and CVV.

However, their "direct debit" option requires you to enter your bank debit card number and bank password into Wise's web form. It is not a redirect to the bank website. The URL says "https://wise.com/..." when you're asked to enter that info. Wise definitely gets your bank credentials.

They have yet another option called "bill payment" in which you log into your bank account yourself and do a bill payment to Wise (and giving your Wise account number).

Both the "debit" and "bill payment" methods look secure and acceptable. But Wise charges a considerably higher fee than with their "direct debit" method. And it always seems to take a day or two for the funds to appear in your Wise account with those other methods. They really want to encourage their "direct debit" method in which they get your bank login info.

Are you in the US? I think Wise’s ways of adding funds vary depending on what’s available in terms of payment infrastructure in each country. In the UK where Wise is based, direct debits are very common for routine payments but do not require a card number. But for receiving money Wise UK’s closest equivalent right now is to authorise payment via open banking and your bank ( the newish UK specs for doing this are really good and online here: https://standards.openbanking.org.uk/ )

I'm speaking about Canada. I should have mentioned that. You're right that the payment options are probably quite different in each country where Wise operates.

Out of curiosity, in Canada (and the USA, where I assume it will be similar), how do you call the system to authorise a business, for example a utility company, to charge your bank account directly every given period, with a more-or-less flexible amount, and with no need for you to take any action?

The reason I ask is that that is what is called a "Direct Debit" in the UK and the European SEPA area, and it does not involve providing any credentials to the bank account. Rather, you only need to provide your International Bank Account Number (IBAN) and maybe your name. However, the ability for a company to be able to take Direct Debit payments is heavily regulated, you can easily cancel them via your bank, and even reverse charges if they were illegitimate.

This is as common as bread and butter in Australia. You provide your bank account (or credit/debit card) details to the company or even govt (gas, electricity, water, car registration, insurance, internet, mobile etc.) and a so called direct debit authority and the company will just debit from your account on the due date.

Yes, Direct Debits or similar are something that I would normally assume is commonplace in every developed country. However, I'm so aware of the American TV trope of receiving "bills" in the mail and having to remember to pay them that I wonder if it's just something that has stuck as a cliché even if it's no longer the case, or whether it is still the ordinary way of handling these payments in North America.

Yeah, direct debit is a very specific, well-standardised thing in the UK and comes with a fair amount of consumer protection. It’s also a bit Oauth-ish in that you can unilaterally cancel it from your bank’s side of things instead of going through the provider.

Can confirm that Wise use Open Banking API to send money in the UK, if your bank supports it. If your bank doesn't support it, it's either debit / credit card or bank transfer.

> 2) Which raises the question about why the banks aren't blocking IP addresses that Wise uses to log into bank accounts, or at least making a complaint to Wise.

People doing screen-scraping like Plaid will seek out IPs that look innocuous. One place I heard of had bank of mobile phones all with cellular data plans hooked up to some UI automation. This lets them run screen scraping from a real phone on a real cellular network.

Also look at the company Luminati Networks/Bright Data: https://brightdata.com/proxy-types/mobile-residential-ips

They pay app developers to install an SDK on their popular mobile apps, then sell the right to run network requests through users devices. Perfect if you want to do some sketchy screen scraping and need access to a lot of innocent looking IP addresses.

> Wise (formerly TransferWise) is another example

It is not. The direct debit feature you describe is provided by Plaid.

Wise itself says so in this TrustPilot answer https://ca.trustpilot.com/reviews/60e668daf9f48702a893a5e6

> It sounds like you might be trying to make a ACH direct debit payment, in which case Plaid is indeed one of the payment handlers that help us process these types of payments. However, we also offer other payment options for USD, if your account isn't able to support ACH direct debit.

There are other sources mentioning TransferWise is a customer of Plaid like https://www.digfingroup.com/plaid-visa/ and https://politechs.ca/2020/09/09/visas-acquisition-of-plaid-c...

In Australia Wise will provide you with a reference number and hold the xfer and wait for me to transfer the money to them. Wise has a unique email called a PayId that is registered to their account.

I use my banks app and transfer money to their PayId using the reference number. The transfer takes a few seconds. When Wise gets the money in their account they resume the transfer and I get an in-app notification. Easy

In what country does it have that option? Doesn't seem to be a thing in Australia as far as I can tell. But we do have multiple different ways of doing free (or free for the sender and very low cost for a merchant) payments and transfers, including real-time transfers to/from financial institutions...

Given that it seems to be a similar case in Europe, UK etc. I assume this might just be a US thing?

Australia does have other examples of these systems though, like poli (https://www.polipayments.com/) which is commonly used by airlines to accept and prove direct deposit payments

I work at Plaid, and I responded to this on the parent, but because this is pretty highly upvoted I figured I'd respond here too for visibility: the Consumer Financial Production Bureau addressed the fact that a financial institution cannot waive liability responsibilities in a recent Compliance Aid. FAQ 4 says that institutions cannot rely on an agreement with the consumer that waives the liability protections under Regulation E if a consumer has shared their account information with a third party because those are protections provided under the Electronic Funds Transfer Act.

Source: https://www.consumerfinance.gov/compliance/compliance-resour...

Regulation E does not waive consumers' liability for unauthorized transactions; it merely limits the amount of liability. The liability limit increases sharply if the consumer does not report the fraud within 48 hours.

Also, that's US regulations. The article is about Canada.

I'm pretty salty about this. It's totally unethical, they knew it wasn't legal, and yet... they're going to be OK outside the fine?

Why do we bother being ethical when nobody besides us gives a shit outside a slap on the wrist?

You know how many people thought of Plaid before it was a thing, then rightfully wrote it off as "don't attempt"? What kind of sick precedent does this set?

Why do I even bother caring.

> they knew it wasn't legal

Who knew what wasn't legal? I don't think anyone is doing anything illegal here?

Coercing credentials out of a user is phishing. I was wrong in that it may not be technically illegal, but are we really going to dispute if phishing is acceptable behaviour for a company to participate in?

You already know the answer. Ask forgiveness not permission, move fast and break things.

Our profession is such a joke. We're no better than the stereotypical trades worker of yore... a bunch of plumbers scamming and ripping off the every day person that doesn't know any better. Truly pathetic.

Or perhaps it is our systems that are pathetic? Laws, regulations and enforcement thereof has always been a bureaucratic effort.

As an early career engineer, who works at a highly bureaucratic company, I always asked for permission for access to things I needed for my job. The gate keepers would ignore me. Worst example was when my management asked me to start version controlling a project I created. I had to work with the change management department, it took them six months to create a repo on a server just because no one knew the person who knew how to do that, and they had to be the ones to make it, not me.

Then I moved up in the company and got direct communication with the customer. The gate keepers come to me, not the other way around. Repos get created in a day now.

The problem with every bureaucracy is the incentives are never aligned with the organizations stated mission. When you say “version control” what you really mean is version control for employees who directly bring money to the company, for which we’ll dedicate significant parts of our budget to employ people for a function that can be automated as some sort of make-work scheme. The incentives are messed up.

Bureaucrats only win when they don’t get fired, and they don’t get fired when they follow the policies and procedures. And policies and procedures are there for the well trodden happy path. If you are innovating, there will, by definition, be no happy path, you have to make it, and if you ask a bureaucrat for help, they’ll seize up because there is no procedure to follow. At best they’ll direct you to someone else, who will also seize up and direct you back to the same person who sent you.

I discovered that the best way around that is to make seizing up a more likely way to visibly fail. I need you to help me get this build out to the customer TODAY if failure to do that will result in higher consequences than failing to follow procedures, they will make the build.

So moving fast and breaking things can get you to that high consequence state that bureaucrats seem to budge on. If you have a successful startup that breaks the law, you can please your users, and afford lawyers to defend you in court and afford PR firms that can convince the media to harass your regulators on your behalf.

I've been thinking about this quite a bit recently. I essenrially agree with you, software engineering culture/habits is nowhere close to actual "engineering". One suspicion I have is that this was largely enabled by the fact that software companies, in contrast to most hardware businesses could denounce liability for their products.

The thing is, because software companies have become the most successful businesses in the world, SE principles (move fast, break stuff) are now viewed as "being innovative" and necessary for success. So they are increasingly being applied to other engineering disciplines.

I don’t actually share your low opinion of trades people current or of yore - and even the most unethical plumber isn’t financially ruining people by the tens of thousands. All the to say this profession can be MUCH worse than the tradespeople of yore

And the fine was a joke... less then $1 per person affected.

> Nearly 98 million people were affected, according to the settlement

I haven't used Plaid, but how is this different from Mint or Quicken that have been around for years?

Mint and Quicken are end user applications, Plaid is not. Plaid is an API provider to access financial information from multiple institutions.

Ok, but it's like the portion of Mint or Quicken that interfaces with financial institutions, and it enables end user applications, right?

When I wrote "how is it different" I meant how is it different in the task it performs which (I assume) Mint and Quicken also perform.

Mint also did screen scraping, powered by Yodlee [1], if that’s what you mean. So, yes, same risks as Plaid.

They later moved off of Yodlee to Intuit APIs, post acquisition, although those also do screen scraping [2], and thus carry the same risks.

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

[2] https://money.cnn.com/2010/12/02/pf/mint_leaves_yodlee/

As someone who attempts to import all my own banking transactions into open-source personal financial software, I certainly don't like the situation, but banks often give someone looking to download their own financial transaction data no other choice. This is basically what Intuit/Quicken do for 'Quicken Web Connect', too...

Additionally, though I think the advent of new APIs which will allow you to authenticate directly with your bank (FDX) are a great improvement for overall security, I think they're going to be a step backwards for free access to your own personal financial information. Because banks are limiting access to FDX to large players like Plaid/Quicken, I fear you will be forced to pay a third-party to get your own personal financial data in the future!

Don’t tie banks have extra steps to do things beyond read-only authentication?

My bank requires 2FA to send money to new payees. While losing my user/pass would lead to information leak, there’s little chance of my money being shipped off without further breeches.

How would they know about that transaction I made today without my password?

This is FUD. Lots of Plaid-based connections only allow reads. This is a regulated industry, and the fallout reputationally might be tough, but consumers are well-protected.

Is it, though? I’ve given Plaid the user name and password to my bank account. The same set of credentials that I use to log in, to pay bills, transfer money, etc. Plaid stores this information for future use in some sort of reversible encryption. So now we trust Plaid to keep both their data set of user names and encrypted passwords secure, and also to keep their decryption keys secure. Forget that noise. Like the previous commenter , they’re one breach away from exposing millions of bank account credentials. It doesn’t matter if the Plaid API is read only for the integration side - somebody has MY credentials, and that’s not read only.

Eh, it’s herd security. Hackers with credentials may pick off a few people’s accounts, but the odds of you being hit are low since it’s a hard problem to scale and there’s so many targets.

For the 0.3 seconds until they automate emptying accounts...

If all Plaid's customers accounts were emptied in one go, I suspect banks would reverse those transactions and tell any counterparties that lost money to pound sand.

I believe the cool kids call it a "hard fork", as in, if you are the bank that received the stolen funds and let someone withdraw them, you get forked, hard.

You wouldn’t drain all accounts all at once. Pick a couple accounts to satisfy your needs and drain them. Harder to get caught.

How is that enforced? What is the technical basis that enforces read-only access using user/password auth? Especially since that user/password auth is used by an end user to do "write"-type actions?

It's enforced - sometimes - by the bank. My bank provides read access to everything with a username + password, but to transfer money or update details requires an SMS confirmation.

I remember a presentation by the head of security of an Internet-only bank years ago, about banking malware.

The latest malware was a man-in-the-browser style one: it intercepted your input and changed what you saw on-screen. This was used to defeat extra authentication: the malware inserted a (fake) deposit (something like "yearly subscription mr. X" for $2134.56) into your on-screen total and phoned home. The victim was then called by a mr. X who claimed to have accidentally swapped two digits in a transfer, and that the bank had said they can't fix it because the target account was a valid account. All they could do was exceptionally give out the phone number of the receiving side. Would you be so kind to rectify the situation?

Since mr. X had all the details correct (amount, statement on transaction), the victim would initiate and authenticate a transfer. No way for the bank to detect, as this wouls be a genuine transfer order by the account owner.

To be clear: the attack requires a victim whose browser is hacked and an associated phone number. That seemed like a tall order to me, but apparently not tall enough to stop this attack from being integrated into multi-banking malware.

In short: read-only access is good, but not sufficient to prevent all attacks.

That type of hack doesn’t require the user/password. It’s also on the same league as the Nigerian Prince, just appealing to kindness rather than greed.

Idiots fall for these scams all the time, password not needed.

Read-only access is not possible. By handing over the credentials you are handing over write access. You are correct.

A couple of my banking institutions let me generate a read-only set of credentials for this sort of purpose.

Citi and Capital One have OAuth flows that Plaid supports, too, which tends to make me angrier at the banks than Plaid; the need for this stuff has been clear for a decade now, but only a few have added OAuth or similar.

AFAIU, there are still zero (0) consumer banking APIs with Read-Only e.g. OAuth APIs in the US as well?

Banks could save themselves CPU, RAM, bandwidth, and liability by implementing read-only API tokens and methods that need only return JSON - instead of HTML or worse, monthly PDF tables for a fee - possibly similar to the Plaid API: https://plaid.com/docs/api/

There is competition in consumer/retail banking, but still the only way to do e.g. budget and fraud analysis with third party apps is to give away all authentication factors: u/p/sqa; and TBH that's unacceptable.

Traditional and distributed ledger service providers might also consider W3C ILP: Interledger Protocol (in starting their move to quantum-resistant ledgers by 2022 in order to have a 5 year refresh cycle before QC is a real risk by 2027, optimistically, for science) when reviewing the entropy of username+password_hash+security_question_answer strings in comparison to the entropy of cryptoasset account public key hash strings: https://interledger.org/developer-tools/get-started/overview...

> Sender – Initiates a value transfer.

> Router (Connector) – Applies currency exchange and forwards packets of value. This is an intermediary node between the sender and the receiver. {MSB: KYC, AML, 10k reporting requirement, etc}

> Receiver – Receives the value

Multifactor authentication: Something you have, something you know, something you are

Multisig: n-of-m keys required to approve a transaction

Edit: from "Fed announces details of new interbank service to support instant payments" https://news.ycombinator.com/item?id=24109576 :

> For purposes of Interledger, we call all settlement systems ledgers. These can include banks, blockchains, peer-to-peer payment schemes, automated clearing house (ACH), mobile money institutions, central-bank operated real-time gross settlement (RTGS) systems, and even more. […]

> You can envision the Interledger as a graph where the points are individual nodes and the edges are accounts between two parties. Parties with only one account can send or receive through the party on the other side of that account. Parties with two or more accounts are connectors, who can facilitate payments to or from anyone they're connected to.

> Connectors [AKA routers] provide a service of forwarding packets and relaying money, and they take on some risk when they do so. In exchange, connectors can charge fees and derive a profit from these services. In the open network of the Interledger, connectors are expected to compete among one another to offer the best balance of speed, reliability, coverage, and cost.

W3C ILP: Interledger Protocol > Peering, Clearing and Settling: https://interledger.org/rfcs/0032-peering-clearing-settlemen...

> Hopefully individuals will be able to use the Open Banking APIs to access their own data directly, but it looks like accreditation will be required, so probably not.

When you loan your money to a bank by depositing ledger dollars or cash - and they, since GLBA in 1999, invest it and offer less than a 1% checking interest rate - and they won't even give you the record of all of your transactions as CSV/OFX `SELECT * FROM transactions WHERE account_id=?`, you have to pay $20/mo per autogenerated PDF containing a table of transactions to scrape with e.g. PDFminer (because they don't keep all account history data online)?

Seemingly OT, but not. APIs for comparison here:

FinTS / HBCI: Home Banking Computer Information protocol https://en.wikipedia.org/wiki/FinTS

E.g. GNUcash (open source double-entry accounting software) supports HBCI (and QIF (Quicken format), and OFX (Open Financial Exchange)). https://www.gnucash.org/features.phtml

HBCI/FinTS has been around in Germany for quite awhile but nowhere else has comparable banking standards? I.e. Plaid may (unfortunately, due to lack of read-only tokens across the entire US consumer banking industry) be the most viable option for implementing HBCI-like support in GNUcash

OpenBanking API Specifications: https://standards.openbanking.org.uk/api-specifications/

Web3 (Ethereum,) APIs: https://web3py.readthedocs.io/en/stable/web3.main.html#rpc-a...

ISO20022 is "A single standardisation approach (methodology, process, repository) to be used by all financial standards initiatives" https://www.iso20022.org/

Brazil's PIX is one of the first real implementers of ISO20022. A note regarding such challenges: https://news.ycombinator.com/item?id=24104351

What data format does the FTC CAT Consolidated Audit Trail expect to receive mandatory financial reporting information in? Could ILP simplify banking and financial reporting at all?

FWIU, RippleNet (?) is the only network that supports attachments of e.g. line-item invoices (that we'd all like to see in the interest of transparency and accountability in government spending).

W3C ILP: Interledger Protocol. See links above.

Of the specs in this loose category, only cryptoledgers do not depend upon (DNS or) TLS/SSL - at the protocol layer, at least - and every CA in the kept-up-to-date trusted CA cert bundle (that could be built from a CT Certificate Transparency log of cert issuance and revocation events kept in a blockchain or e.g. centralized google/trillian, which they have the trusted sole root and backup responsibilities for).

Though, the DNS dependency has probably crept back into e.g. the bitcoind software by now (which used to bootstrap its list of peer nodes (~UNL) from an IRC IP address instead of a DNS domain).

FWIU, each trusted ACH (US 'Direct Deposit') party has a (one) GPG key that they use to sign transaction documents sent over now (S)FTP on scout's honor - on behalf of all of their customers' accounts.

Regulated by settlements over this specific allegation lmao

Consumers are only protected by people pointing this out over and over again

To be fair, YNAB is rather explicit about how it connects to your accounts and also actively recommends against doing so in favor of manually entering your transactions. My experience with connecting the two is that I still need to manually validate every transaction because on occasion Plaid is either slow or just misses entries entirely.

Also in the case of YNAB, Plaid is not posting transactions on your accounts. It's a screen scraping service transferring account data.

I manually enter all of my transactions, but for correcting mistakes or for automatic payments, linking to my bank accounts is still very useful.

Also, some accounts update faster than others for some reason. Usually YNAB will import them the same day.

Plaid doesn't post transactions, but it does have my credentials which I said I would not share with anyone when I opened my bank account. Those credentials do allow posting transactions, and while it's not likely that anything will happen, if something does, I'm theoretically responsible. At the moment, I'm willing to take that risk.

FWIW I use Schwab for banking and I was able to connect YNAB to Schwab without entering my password. It looks like Schwab supports read-only API access, and Plaid takes advantage of that to avoid needing your credentials.

As an added plus, you can keep 2FA enabled. Schwab does 2FA through an app so it's a touch above SMS-based 2FA (although only a single app is supported, Symantic VIP Access, rather than generic support for apps like Google Authenticator).

I also hate Plaid's model where you provide Plaid your credentials, and I've never entered my credentials into Plaid.

If you trust python-vipaccess[0], you can use it to provision the token to load into your preferred TOTP app. It’s not a supported method but if you (or someone coming across this later) want to use another app it’s an option :) From WilsonHammer on Reddit[1]:

1) Install pip, a python package manager, using your OS package manager.

2) Install python-vipaccess by executing `pip install --user python-vipaccess`

3) Execute `vipaccess provision -p -t VSMT` - this will print out all the information needed. Note the Symantec ID (it looks like VSMT12345678). It is what goes in the "Credential ID" field when adding a new device on Schwab's website.

4) Save the `otpauth://...` data into data.txt.

4.5) (Optional) Modify the `issuer=Symantec` parameter to read `issuer=Charles%20Schwab` Also change `VIP%20Access:VSMT123456789` to your Schwab online banking username. These are purely aesthetic changes and will only make a difference in the label that shows up in the Google Auth app.

5) Install qrencode using your OS package manager.

6) Execute `qrencode.exe -o qr.png -s 15 < data.txt` to generate the QR image (qr.png) from your otpauth data file. The -s 15 scales how many pixels wide a QR block is in the image (in this case, 15).

7) Scan the QR image (qr.png) with your google auth app.

8) Go to Schwab -> Service -> Security Center -> Manage Two-Step Verification -> Add another Security Token and input the Symantec ID from step 3 (it looks like VSMT12345678) and the current rolling TOTP code from the Google Auth App. (If you use Authy you may have to type it manually)

[0] https://github.com/dlenski/python-vipaccess

[1] https://www.reddit.com/r/personalfinance/comments/hvvuwl/usi...

In the UK, which has implemented open banking already, you can use services like https://syncforynab.com/ (no affiliation, just a happy customer) to link your accounts to YNAB. Some challenger banks like Monzo and Starling allow you to set up webhooks for transactions so they're immediately available in YNAB through Sync for YNAB rather than having to use x-hourly syncs via open banking companies that are officially blessed by the big banks.

I recently moved back to the US after 5 years in the UK. It’s hard to overstate how awesome Monzo is, and how much of a steaming pile of 3rd world shit banking in the US is.

Addendum: I still use Monzo in the US. Call the cops. I don’t care.

I haven't read the entire report yet, but it seems like a step in the right direction (even given some of the caveats folks have pointed out). I work at Plaid and a big focus area for us is to move as much traffic to APIs as possible, with a target of 75% of traffic to be committed to APIs by EOY, and we’re hopeful that we’ll be close to a fully API based industry in the next few years. IMO anything that makes API-based connectivity and open finance standards more widespread is a win for both fintech developers and anyone with a bank account.

It’s worse than that. I assume Plaid doesn’t scrape bank sites and rely on 3rd parties to bypass the EULAs on bank sites.

Hi! I work at Plaid. This is false. We do not do that.

Ever? That was always the rumor on how aggregators could fix scraping within a day of major changes.

If the supposed third-party scrapers can do it within a day, why wouldn't Plaid/Mint/Yodlee be able to do the same?

can you please elaborate? this is quite the accusation

It is something I heard working in fintech, a lot around security, that the aggregators rely on 3rd party scrapers. Not plaid specific.

I think the future is that banks/bank apps will do the budgeting stuff themselves. Most bank apps will now break down your monthly spending by categories. My bank app shows me my weekly and monthly spend compared to previous periods, how much I spent in each category, how much I spent at each business, how much I have spent this month so far compared to the same time last month and etc.

I hope not. I have accounts at more than one bank, and need to have the data centralized for it to be useful.

Having a standard and open API across banks, brokerages, and credit providers would be killer.

My bank does that too, and has done so for many years now. It's close to useless though, because I have no control over it. YNAB isn't just historical trends, it's a budgeting program.

Startups prove the model, and then legacy enterprises adopt.

Uk banks are doing this now. You can use open banking to show all your (uk) accounts in one place

Hi! I work at Plaid wanted to share that the Consumer Financial Production Bureau addressed the fact that a financial institution cannot waive liability responsibilities in a recent Compliance Aid. FAQ 4 says that instititutions cannot rely on an agreement with the consumer that waives the liability protections under Regulation E if a consumer has shared their account information with a third party because those are protections provided under the Electronic Funds Transfer Act.

Source: https://www.consumerfinance.gov/compliance/compliance-resour...

That's for the USA. This news is about Canada.

But still. Terrible security model, right?

Dunno how Turbotax does things under the hood in the US, but when it prompts me for the username and password of my broker to import my info, it certainly make me very queasy.

This is basically the main reason why I built uFincs (https://ufincs.com/) without any sort of bank integration. As a Canadian myself, the privacy implications of letting a third party like Plaid take my bank password to get my data were, indeed, rather sketchy. I've been looking forward to the day that open banking gets pushed here, so this is definitely good news that uFincs (and every other personal finance app) nmight eventually get some secure bank integrations.

Although, knowing how these things usually go, I'm sure the "2023" target is a little optimistic...

>if something goes wrong and Plaid loses my money somehow, is there any recourse

Wait, you mean you don't read and understand every word of every legal agreement you accede to??

Ok, well, as a responsible consumer, have you considered keeping a lawyer on retainer?

I've worked for a heavy customer of Plaid, and I've experienced the good and bad side of said entities and architectures, and the propaganda used by both sides. Banks say "impersonate", Plaid says something else. I think a reasonable viewpoint could say that you are authorizing Plaid to act on your behalf. Would a bank punish a rich person for having their accountant/finance manager know their credentials and use them in their duties? Would a bank publicly punish someone for storing their bank password in a password manager? How about an online password manager?

I don't know what Plaid is. But the user/password thing sounds insane. How can that be even an idea for a solution?

What else is there, when the bank doesn't provide an API & the ability to do something proper, like OAuth2?

There is this alternative: don't create a service that does something like this.

This put me off this type of banking app the first time I tried to register an account with them ten years ago, and I haven't touched them since.

I suppose EU users have an easier time with the PDS2 directive mandating interoperability between banking actors, but I'm unsure how many have found a way around properly implementing it.

> YNAB (You Need A Budget) use services like Plaid to...take my username and password and impersonate me to get my banking data

WHAT. THE. F.

I'm a longtime, happy YNAB user. I had no idea this was going on until just now. I always just assumed there were secure APIs used to import my data. YNAB's Capital One "integration" stopped working a few years ago (possibly because they cracked down on screen scraping?) and I was upset with Capital One. Perhaps Capital One took steps to prevent insecure access/screen scraping?

For future reference the tip off is that YNAB/Plaid asks for your bank account's username and password directly. If they were using some proper API, you'd be redirected to an Authorization page on your bank's domain where you could review the requested permissions and the app requesting, and then choose to grant it.

Exactly this, Plaid "kindly requests" you violate the ToS you have with the bank and hand over the keys to your finances.

I have never noped out of anything so hard.

It would be interesting if an attorney general went after Plaid for CFAA violation.

I'm conflicted on the issue. Plaid only has to do this insane screen scraping because there's no other way to get my own financial data. The details of how it's done pains me, but I also think I should have freedom of choice with my data.

IMHO, the Canadian proposal seems like the ideal solution. Force the banks to offer a secure and more efficient way for consumers to access their open banking data. (This will also massively lower the barrier to entry for another Plaid competitor)

edit: Plaid's docs mention that banks may detect and block this screen-scraping. They frame it as the bank limiting "your ability to access your financial information", which I think is somewhat valid. They're quite obtuse about the whole scraping thing though: https://plaid.com/trouble-connecting/#:~:text=Your%20financi...

I'm not conflicted on it at all. Plaid might need to do this for them to work, but there's nothing that makes Plaid required for anything you do with your banking. People keep mistaking convenience for necessity, and that's how we keep ending up with hacked-together services that leak everyone's info and worse.

I'd rather have no convenience than a convenience that hands off the keys to my life behind my back. And so should the rest of us.

You're basically saying that if a law makes something impossible, then it's OK to ignore the law?

This is how most old/out of date laws/not fit for purpose laws end up being revised.

Hi! I work at Plaid. We’re strong advocates for API-based connectivity -- our goal is for 75% of our traffic to be committed to APIs by the end of the year. As part of that, we've actually converted our integration with Capital One to be 100% API-based and use OAuth for authentication. You can read more here: https://www.capitalone.com/about/newsroom/data-sharing-agree...

What you did was wrong and you all knew it.

It seems to have paid off though, so congratulations. Nobody with half a brain would trust you.

Let's be real, banks wouldn't see government regulation like this if something like Plaid didn't force them to have to implement more secure ways to get your own financial data.

I actually do agree - but two wrongs don't make a right here. Taking raw credentials from users without them knowing is completely messed up and a massive danger to the end-user. It's not justifiable in those terms.

Yes I agree it can be scary, but it seems like this is the way a lot of companies have to do things if they want regulation to change at any reasonable pace.

Just look at Uber and AirBnB as examples. Most cities they started in they were operating in kinda grey areas or even breaking laws. But they could afford to eat any fines and continue on anyway. It forced governments to put regulations in place to support these systems.

Especially when it comes to banking, it moves at such a snails pace for anything to ever evolve. The two banks I am with in Canada only just recently finally added support for 2FA. But it's not even the type where you can use your own authenticator app. You have to use SMS, Phone Call, or their app. My one bank has my "password" being restricted to 6 characters. It's basically got to be a 6 digit pin. It's incredibly insecure already, Plaid doesn't make it much worse.

Now with 2FA finally there I feel a lot more secure using Plaid. Because now everytime I want to import my transactions in YNAB I have to enter my 2FA code before it can pull things.

But is it a good thing for companies that are rich enough to be able to force changes in regulations by overwhelming the government's ability to punish them?

No, it definitely is not. Governments notoriously move slow and they do not often keep up with the fast moving pace of technology.

Governments for the most part worldwide have still done barely anything to address things like "loot boxes" in gaming despite them being almost identical to gambling. They aren't even getting fined or anything for this and are raking in billions of dollars. So whether or not big companies are doing things to break regulations they can still be doing things that should be regulated or are not ethical anyway.

The taxi industry was pretty bad and often filled with scams and corruption. One of the cities I live near only allowed one cab company to be licensed in the city and they sucked especially when people needed rides home at night. So when Uber came in people loved it because they could finally get home safety after a night of drinking and it discouraged people from having to try and drive home drunk. For whatever reason the city always only allowed this one cab company. It would be reasonable to think a city official had some affiliation with that company to not allow other cab companies to come in.

Uber forced that to happen and it forced them to make regulation for it. There seemed to be no progress in that happening before Uber came to town.

So while Uber has some pretty shitty practices and I wouldn't consider it a good company, it is definitely a good example of what often needs to be done to force regulation.

And I mean a city always had the option to increase their fines to something massive and hit Uber hard, but instead they realized that their population wanted that and they would likely lose a lot of votes if they did something against the people like that.

Literally the only way for apps you want to use with your own financial details is to screen scrape.

Plaid better have good security!

But I don't see this as unethical in the slightest. In fact, I see it as a company doing the right thing by consumers in letting them get access to their own data.

I don’t see this as wrong at all, it’s an extremely useful feature with no alternative. Actually if alternatives start to appear it’s to services like theirs.

And insulting their whole user base like this sure will get you lots of support.

Do you make it unmistakably clear for new users that if you have a data breach and someone loses $400,000 because you leaked their password, they are likely shit out of luck?

Don't know US regulations, but my country has plenty of case law determining that the customer is liable for every single dollar of loss if someone uses their account details to steal their money or take a massive loan in their name.

Is there a list of which institutions you support using APIs versus screen scrapers? I'm a happy user of YNAB and would like to have automated imports for any bank that can be read from securely.

Unfortunately, there isn't a comprehensive list that I'm allowed to share, and even if there were we're often rolling out API access gradually because it can require implementation changes on the developer's side (for example, to support an OAuth redirect flow), so it's possible that right now a particular institution may be accessed via API in one Plaid integration but via screen-scraping in another. I think the only thing I can say here about specific institutions is that of the major US banks, Capital One, Chase, Wells Fargo, and US Bank have all issued press releases indicating that they have signed agreements with us to provide API based access.

I'm sure you guys started at that point and realized it was not possible because the banks didn't offer it, didn't understand why, and didn't care about you

And now after you made your solution and gained traction with many fintech apps, the timeline was accelerated by FTC settlements

But don't get the order twisted, you're trying to plai us.

You gave them your bank account login credentials and you didn't think it was strange?

Plaid has designed the screens to resemble each bank's login screen. They essentially phish people. I, as a tech-savvy person, noticed something was up when I saw the URL didn't match my bank's. But most people would put in their password, thinking they are logging into their bank's website, and would be none the wiser.

OK, I work at Plaid and I feel like I have to jump in here -- while it's true that we've iterated on the Plaid Link UI over time and it hasn't always looked like it does now, you can see what the login screen currently looks like here: https://plaid.com/plaid-link/ and here: https://plaid.com/demo/

IMO it does clearly tell end users that they are connecting to Plaid.

So some good finally came from that TD lawsuit. The last time I saw a Plaid login in a service I use, it was a definite phishing screen. It's good that you have moved away from phishing people, but it doesn't change the fact that a) you phished them for years, and b) you still do not in any way warn them that if they use your service it 'voids the warranty', so if their account gets hacked (not necessarily through Plaid), they will be SOL.

As another HNer responded: cred screens are given the appearance of being your financial institution, so I assumed an api auth token being issued after “logging in” with the institution. Still, shame on me for not inspecting more closely.