We let developers bring their own KYC providers. There are so many great solutions out there I don't think the world needs another one :)
In general our approach is to focus on building things that 'only a bank can do' and if there are great existing solutions (ie: fraud, kyc, issuing processors) we let developers bring those solutions. We play nicely with all of them.
In the US (and most countries) in order to get access to the central bank (in the US the fed) and do 'banking things' like holding money, moving money, and lending money you have to have a banking charter. We have a national charter (issued by the OCC) but you can also have some other more bespoke charters as well!
I believe they're looking to imply here that they own their own charter, rather than renting someone else's, which is how almost all U.S. fintech companies operate (look in the website footer of, say, Unit and you'll see: "Banking services are provided by Unit's partner banks who are Member FDIC.")
this is an important point. There are other providers who offer programatic creation of bank accounts, payments, etc. But all existing solutions wrap a bank, who then wrap middleware providers and core systems. When you work with Column, you're working with only Column. This has implications for cost (fewer people taking a slice of the pie), performance/usability/experience (modern, tightly integrated systems), and development velocity (fewer players in the game of Telephone). Column collapses the layers of the financial services stack and exposes this functionality via API.
I’m sure costs is part of the equation but I’d imagine the control is far more important. Reselling legacy bank services means you’re limited to what they can do, which is usually not much. Most finance technology is heavily limited by what they can do… because of their partners, and that’s why they’re usually just nicer interfaces to the same old services. Hence banks like Monzo in the UK building their own infrastructure from the ground up too. The less you’re dependent on legacy technology, the more you can do.
Right now I have an account now where I can deposit USDC and spend via tap to pay/debit card. Basically just a debit card linked crypto account, rewards are $$$ (4%) and adjusting balances is fast and easy. Also programmable so I can replace what is spent without having to manually transfer. This helps tremendously with managing the families access/budgeting of funds.
Would also be nice to have an account where legacy payments (ACH) can be made that also has an interface to deposit USDC. Right now I need to ACH deposit to my bank account (from crypto), and then ACH withdraw to pay the bill. Eventually you could just get rid of the ACH part and convince the accounts receivable to accept USDC (and profit?).
Bringing both these services under one roof so it is a bit easier to manage would be the holy grail of legacy and future financial products.
Hey founder (and OP) here. This has been a labor of love for the past few years and I'm super stoked on what we shipped. Would love any and all feedback, thoughts and questions!
I'm excited about this because it may help with a problem I've had for many years: in a word, being my family's CFO.
I'm a data scientist, and I'd like to be able to report as easily on my own personal finances as I can on the data of the company I work for. This is not a small thing for me. I want to take care of my family's finances, but I'm impatient with bullshit. I don't want to spend an hour every weekend logging into 10 different services, clicking on 10 different things in each company's always-different, always-shitty web UI to pull all the data I need. The easier and more convenient this is to do, the better job I will do managing my money and protecting my family.
As a data scientist, I can handle writing a little code to make some API calls and crunch the numbers that come back. If APIs were available to me for all companies I have assets or liabilities with, I'd have no trouble being an awesome family CFO. But... there is nobody that wants to make this secure and easy for me!! I would have to go to a company like Personal Capital, give them ALL MY ACTUAL BANK LOGIN CREDENTIALS, and they'll go login and do some screen-scraping to get the data. Half the time that won't work because of 2FA complications. They'll bring that data into their little ecosystem, serve it through some shitty web interface, and use it to serve me whatever ad nonsense they want. It's immensely unpleasant, slow, unreliable, and insecure. It sucks ass.
Is your company going to fix this, or perhaps be one part of the solution? One day, will I be able to run my own R and Python scripts that pull all my data, balance my checkbook against receipt screenshots, automatic fraud detection, show me how all my investments are doing? Maybe even open-source it so that others can do the same?
Thank you so much, in advance, for reading and any reply you can make! I'm very excited for this!
You might be interested in Tiller Money https://www.tillerhq.com/. They provide something very much along these lines, with the output being an auto-updating Google Sheet that you can do whatever you like with. You do still need to update credentials sometimes, but I've been using it for a few years and it works quite well.
Hey there, you will be able to do all of this with our Klutch credit card. Full disclaimer I am the cofounder. But what we built is exactly what you are describing. Here is a link to our documentation- https://dev.klutchcard.com/docs
I would set all accounts to send monthly/weekly statements and get PDF's that way into an email. Then all that is needed is a python downloader + scraper + visualizer based on how much automation you need.
I'd avoid using any service to do this for you after what PLAID pulled off on people by storing their credentials and getting more info than what was actually needed.
This seems to be the US equivalent to Solarisbank, which operates only in some EU countries. I don't know any specifics, but I have encountered Solaris a few times. For example they are used by TradeRepublic, basically the German Robinhood equivalent, and a handful of Neobank providers. Those Neobanks usually focus onto a specific niche and build their product based on the services offered by Solaris.
I would imagine that Column could provide similar their services to similar companies and make the development of financial products significantly faster.
I imagine these limitations are going to be a moving target as they grow.
A lot of developer driven organizations are very happy to outsource complex parts of development to managed services so they can focus on their core differentiators, especially when it comes to parts of the stack that need super high availability and security. This is why Auth0/Okta are big businesses and not everyone rolls their own key cloak / shibboleth instances, as one of many examples.
This clearly seems like the Apex/Drivewealth model but for challenger banks or new online banking operations. It is hard to predict what startups or new projects will need this because those platforms can unlock innovation for new categories (e.g. no one imagined commission free trading in 2008, and Robinhood wouldn't exist without Apex).
I guess my point is that payment and ledger back-ends aren't the hardest part about running a bank, they aren't even the hardest technology component. This isn't "for developers" in the same sense that Stripe is. It is for people ready to run a bank. Sure it will save you paying lawyers and regulators for charters and it will save you from buying a mainframe to run some crufty COBOL ledger but that still leaves a lot of yak shaving before you even get to the interesting part of your Fintech product.
Okta is successful because almost every application needs authentication, almost every organization needs SSO, and no one considers it a core competency.
The intersection of organizations who can run a bank but don't already have entrenched software to do so, and want to build all the other software themselves seems vanishingly small.
> The intersection of organizations who can run a bank but don't already have entrenched software to do so, and want to build all the other software themselves seems vanishingly small.
Most FinTech is like this though. User Facing front end custom services built on top of bank infra. The bank infra is typically a bank partner and rarely is something like Stripe depending on the exact use case. This basically provides an intermediate alternative between Stripe and bespoke banking relationship.
Column's website says the company is "100% founder and employee owned."
I'm curious about that ownership structure. I'm assuming you're not organized as a worker cooperative, with a "one worker, one vote" structure? Would you be willing to offer any details about the ownership stake of the founders vs. the other employees and what sort of decision making employees' ownership stake entitles them to?
"Employee owned" almost always just means the company has an ESOP.[1]
It doesn't mean employees get any say in anything at all, it just means the employees are the company's shareholders. The board and upper management still has full say in all policies and operations.
Source: I worked almost exclusively at employee owned companies (though not intentionally). Working for an employee owned company is not meaningfully different than working for a public company or private company.
BTW, ESOPs have significant tax advantages for a founder [2]
This looks like an awesome shiny tool but I'm not sure what I could do with it!
Some Use Cases of successful or hypothetical customers using your product might help other understand how they can use Column for their business.
Is Column Use case to create cards/accounts for a business' customers like Apple did with the Apple credit card?
In my case, I'm the founder of https://www.waiterio.com which is a B2B order management system for restaurants... can I use Column to offer bank accounts and cards to restaurants owners? Or restaurant diners?
What are the winnings for me related to revenues/branding/customers retention?
Yes, you can use Column to create and offer bank accounts as well as build debit/credit/charge programs. There's a part of the website that describes some common use cases https://column.com/docs/guides/#use-cases
Here's an example of what one could do building off a platform like Column:
I previously worked at Center (https://getcenter.com), which after a few pivots, landed on offering expense management and analytics software to businesses. They partner with a vendor (not Column) to issue credit cards.
Center gets a realtime feed of card activity into their system to properly categorize the spend based on various signals or rules, which may, for example, prompt employee to attach a receipt. They focus on companies with decent T+E spend because they get the card interchange fees — that's the biz model: earn money from the card spend / merchant fees (as opposed to competitors such as Expensify that charge per user/card/report/etc).
And for the business using Center cards, they get nice software, instant visibility into spend, spending controls, et al, all at no cost to them. I don't mean to make this an ad for Center (I have zero financial stake in the company), just illustrating what you could do atop a platform like Column based on this specific example I worked closely on.
According to Column, their credit card service remits 100% of the interchange fee to the developer company, so you could build any number of services to enhance this data and service.
I wanted to make a community bank and then build the software to run it and start selling to other credit unions / community banks and start getting rid of the jack henry crap everywhere.
The product looks incredibly good. What I absolutely love the most is the fact the web site immediately addresses people with a human language at the left and plain code at the right. No marketingspeak. Love it.
However the title is a bit misleading. It says "a chartered bank for developers" while the correct title would be "a chartered bank for U.S. developers". I feel like in the IT community we see deeper diversity of nations and citizenships compared to the other industries, so much more people from the rest of the world.
To make sure I had to dug into the documentation. Indeed, US-specific properties are marked as required in the person creation API call[1]. So Column is a non-starter for anyone outside the `default_country`. It would be nice to mention this somewhere on the site perhaps to set proper expectations.
I don't see a link on your website to Column N.A.'s legal disclosures. I'm trying to determine whether you have your own direct connection to FedWire/FedACH, are going through a 3rd party service provider like Fiserv/FIS, or are going through another bank.
Oh, that’s good to hear. You should be in a good position to add support for FedNow having your own in-house connectivity solution. How are you feeling about being ready for that?
From what I gather this is the Tesla of banks (comparing new kid on the block to the old guard – Tesla vs GM): meaning it's a modern bank with systems that run on something newer than COBOL with an open API. It's extremely cool and looks like it may set the standard of what banks must be in the future to compete with newer generations coming into the market.
The most direct connection possible to the federal reserve with as little overhead as possible, accessible entirely over battle tested modern network API technology
We plan on rolling out some corresponding banking services this year to help people with multi-currency accounts and international wires - but it would still be under our US charter. No short term plans to go international - there's a lot of ground we need to cover here. We tend to like to go very deep in an area instead of getting to spread thin.
I can tell you MANY countries are NOT being served by services like STRIPE (South Africa for example) ! I always feel like there is a big opportunity bringing "these financial startups" to where the major players are NOT.
Congrats on releasing ! :)
I would use it, if it was available in South Africa :P
Yeah, it's a tough spot. For the big players, there's heavy investment to enter a new market due to local regulations. A local startup could probably do it more easily, but while they grow there's always the risk the big players might decide they're a threat, they want that market, and invest rapidly and dump the local startup.
Excited to kick the tires on this. Assuming it's correct to think of Column as a very special BaaS vendor (which owns its own bank and thus AVOIDS the double program manager problem), how would you compare and contrast your your unique value prop compared to other BaaS vendors like a Unit, Synapse, Treasury Prime?
Would it be fair to assume better economics because your supply chain is more vertically integrated, or is there more to it than that which I'm missing?
Eng @ Column here. Unlike the other BaaS providers, we ARE the bank. So the buck stops with us so to speak. You won't have to deal with middleware or a bunch of other partner banks, which we like to think is a much better experience.
That is certainly great from the experience side of things, but what I'm wondering about is the economics side of things -- that is, will I get more competitive revenue shares than with other BaaS vendors given that you are the bank?
I see you mention this in your docs, but do you provide any tools for the compliance side that would be required to use your API? E.g. if opening accounts on behalf of customers, all of those customers need to go through KYC. Do you monitor transactions for BSA/AML, or is that up to the user of the API?
This is giving me so many flashbacks to my time at jpmorgan. There’s a bunch of wonderfully interesting corner cases I’d really love to learn about how you address!
Hi all - co-founder of Plaid here. We're in the process of migrating this repository and replacing it with a dedicated iOS SDK repo, JS SDK, and (soon to be) Android SDK. However, I messed up the order of operations with this migration and can empathize with the reaction. I personally chatted with a lot of the commenters on the original issue before we did this and more than happy to engage/get feedback from anyone else over email/phone/in-person. Feel free to shoot me an email at william [at] plaid [dot] com if you want to chat/have any feedback.
I don't think people are upset about the repo being "archived" and having lost access to the issue, per se. I think people are (justifiably) furious because you offer a product which is fundamentally insecure in it's current state and seem to refuse to fix it. And it's not that websites which are using your product are susceptible to attacks, but that a malicious website can impersonate your product and it will be indistinguishable from a legitimate site. Let that sink in. A malicious website can be indistinguishable from a legitimate customer of yours, and users WILL enter their banking information. That is the heart of people's completely justified outrage here, and it's baffling that anybody on your security team could have possibly signed off on this. If people on your security team don't see the problem here they should be immediately fired and never work in the security field again. You guys better have some really expensive lawyers, because it feels like you are being criminally negligent here and should absolutely be held liable when some users inevitably have their lives destroyed as a result.
Can we get a way where we can centrally manage linked accounts? I have at least 5 apps that use plaid and I should be able to go to your website and see what authorizations I have enabled and disable them.
Yes! We're actually working on something in this space that I'm really excited about. If you shoot me an email I can get you on the beta and would love your feedback!
There’s no glory in being excited to launch a basic permissions/access panel for end users of an auth product that should’ve shipped on Day 1. Shameful.
Obviously. But why would banks ever do that? They see Robinhood, Lending Club, Venmo, etc as competitors. No way there going to open up API’s to them unless the government forces the banks to do it.
So maybe Plaid will be what Venmo was to Zelle. I have been following this space for a while now. When Plaid came into the picture, it made Yodlee be more open. So maybe in 10 more years we will have open bank APIs.
They have been trying to get banks to have APIs for years with no luck -- ofx/ofc. Mint went their own way for scraping and Watsi died because they did NOT want to do scraping. I was actually surprised when 2 years ago Xero got a "direct integration with Wells Fargo. Synapse got some funding a couple of days ago one can certainly hope
Co-founder of Plaid here. This is not true, we do not sell transactional data to third parties. We make 100% of our money by letting developers build financial applications[1].
And just to point out, there are others that do sell this as part of their business model, so kudos to Plaid for trying to find another way.
https://www.forbes.com/sites/petercohan/2018/07/22/mastercar... (Another "Forbes Contributor" article, so grain of salt on the details)
I do think these aggregated services are a net benefit to the fintech ecosystem overall. However, any service that uses a Plaid type service still could be selling transaction data to third-parties. For instance, Acorns:
>>> Acorns uses Plaid Inc. (“Plaid”) to gather your data from financial institutions...
>>> Acorns and Empyr will use transaction information from your Acorns debit card in connection with the Found Money Plus program as follows:
... to provide participating merchants or Empyr aggregated and anonymized information relating specifically to registered card activity solely to allow participating merchants and Empyr to assess the results of their campaign(s);
That means they are only sharing data from your Acorns debit card, not your external bank accounts. The Plaid part is separate from the debit card/Found Money Plus part.
You also omitted a key quote:
>when you activate your Acorns debit card, you will be asked to enroll in Found Money Plus, a card-linked offer program offered in partnership with Empyr.
The Found Money Plus program is only for transactions on the Acorns debit card, and it is small bonuses for specific spending, for example, 10% cash back at Starbucks. It looks like a company called Empyr organizes these campaigns for the card link offers.
The Acrons debit card is also optional.
If you're getting cash back on a transaction you know the price is sharing your purchases, this concept isn't really new.
You may not sell the data but you give developer's access to bank balance, transaction history, and income streams. Essentially some of the most private aspects of a person's life.
Seems legitimately useful for personal finance tools or loan providers.
However, I know your API is being used by point of sale systems. Seems super unethical for point of sale systems to access any info beyond, is this the right account, does it have enough money. I just hope you're enforcing some kind of restrictions or at the very least warning consumers what they're giving the merchant permission to access.
As long as you're transparent about it in a 30 page ToS then it's all good. Because when you go to checkout at a cash register, you're going to stop and hold the line for an hour or more and read that page.
Not an exaggeration btw, my print dialog estimates that page to be 27 pages printed.
While I'll assume this is only of the customers of a particular product, it is still worrying as many customers may not understand that fact as you are not transparent about your role and the access granted.
It fits 100% in what he's saying. The API grants the developer of the application access to the account history of whoever's logged in. This in no way establishes they are selling anything to any third-parties.
First, I don't think this is usually what is meant when someone is claiming an entity is selling data. My normal interpretation would be that if a company is "selling my data" then they are selling that data to parties I have zero contact or reason to think they would have my data.
I understand what you're saying, but I think it would be less confusing to keep the idea I described above and what Plaid is doing (AFAIU) distinct.
More specifically I understand it as: If I engage with some entity/company/developer and give them the permission and secrets necessary to access my account, they can pay Plaid to make use of them on my behalf in the process of doing whatever it is I gave them that access for.
This activity is, and always has been to me, completely distinct from the activity of "selling my data", although it could result in the one I authorized to access my data through Plaid turning around and selling my data.
When you enter into a transaction using your bank, someone who is not a party to that transaction can see it, and they pay for that access.
Under any framing, that's a third party paying for access to your transaction data.
The user hasn't opted-in if the co-founder of the company is telling people it doesn't happen. It's only opt-in if the user knows it's happening and agrees to it.
If I'm using a financial app, and it pops up with a "App Foo wants to use Plaid to link to your bank", and I go in and enter my banking credentials into that dialog... you're arguing that I have no idea what I'm doing and aren't consenting to anything? Huh?
If you're so confident, go survey Plaid users and find what percentage are aware that Plaid makes money selling their financial transaction history to developers.
Then ask yourself why the founding team goes around and tells people they don't do that.
That'd be a very misleading survey question, as it heavily implies they're selling it to other developers the user didn't engage with at all.
"Are you aware that connecting app Foo to your bank account gives app Foo access to your transactions?" is likely to be met with a resounding "no shit, that's the point..."
So your claim is that the average person on the street understands that if they send someone money on Venmo once, then Venmo gets 24 months of their bank account history?
And your claim is that the point of the user signing up to Robinhood or Venmo is to give Robinhood or Venmo their entire bank account history for the last two years?
I find this implausible. You have an empirical claim. You're welcome to test it.
Thanks for speaking up alehul; for what it's worth, I think it can often be interesting to later reflect on these moments of apparent shame and embarrassment, especially in the context of attempting to speak truth to power.
Accountability and transparency is important long-term; as is questioning possible abuse or misuse of power. Don't be afraid to continue to do so!
Also, always use Hanlon's razor, but it's getting harder and harder to tell genuine conversations from stage-managed ones online, unfortunately. It's the logical extreme of pg's article 'The Submarine'[0].
Here is one discussion from a so-called whistleblower I was involved in. I will let you decide on the ethics[1].
I'm in the ACH space and I personally know a merchant who planned on using them for account verification for point of sale ACH payments. This merchant also planned on grabbing transaction history while they were in there for I don't know what. Analytics maybe? I have no idea if they ever went through with their plan.
This was the merchant, and not Plaid. While Plaid gives such merchants a lot of power, I don't think the ethics issue lies with Plaid (though you could make a good argument that they should grant limited access, and full API access only on a more restricted whitelist basis)
This may be true - but you do still normalize users to the practice of entering their banking login credentials into a web form which is sent to a third party (i.e. yourselves).
In addition I believe the developer gains access to the users' bank transaction history - not just for the duration of their login session, but long-term, which is likely something that users aren't fully aware of in most cases.
Am I mistaken about those?
That is not 'selling' in the historically-used sense of the word, but we are now in a world where 'personal cost' means something different - especially when it comes to services which harvest personal data.
I have my own issues with Plaid, but I think you’re reaching a bit here. Everything Plaid does is opt in by the end user. They’re not selling data unbeknownst to the user (assuming co-founder above is being genuine), the user is giving another service permission to use their data.
As for bank logins...that’s been around since long before Plaid. But I agree there must be a better way. Though I don’t have any great practical ideas.
It's possible I'm overreaching, yep, but I think the past decade has shown - is showing - that simply 'assuming the best' of what will happen with rapid adoption of new technology isn't the most effective strategy. Daemons will come home to roost over time.
Even if users are technically opting in, and even if everything is documented in the privacy policy, a potential end-game here is that startup companies have access to all bank transactions for the people who need to use Plaid - likely people on the ground in the sharing economy who rely on it for payments - and the more fortunate/wealthier folks continue to have financial privacy by virtue of not needing to use it.
Do users have any idea exactly what they're giving up here though? Do they have fine-grained permissions to allow read-only vs write access, and to choose between transaction and account level data? And is there anything that prevents those second-party developers from then turning around and selling data to third parties (besides their own TOS with Plaid)?
Obviously this is a hugely sensitive service, I’m not denying that. But there’s a way to do it right and it seems that Plaid is attempting to do that. So I’m not ready to declare them evil before they actually do anything evil.
Many (most?) banking websites allow transferring money through the UI. A screen scraper technically has the same access.
Unfortunately the current approach of the major aggregation players is the only way to motivate the banks to give customers access to their own data through more reliable means.
It's a big question that I don't have the answer to. I'd prefer we trade off on some innovation on features in exchange for innovating the way we segment and communicate our data. But the market is speaking and it has a different opinion...
Haven't we on this same website celebrated various Gmail clients and services? Same kinds of risk there (email being different than transactions, but in many cases, that may be worse)
The product is obviously amazing, and I know for a fact that it's creating credit opportunities for consumers with credit history that may not accurately reflect their current financial status, but there is an insidious aspect to the product: the 6 months of future access to transactions and banking information. Most consumers don't realize they're giving this up when they use your product and I believe they would be much less likely to use it if they were aware.
> the 6 months of future access to transactions and banking information. Most consumers don't realize they're giving this up when they use your product and I believe they would be much less likely to use it if they were aware.
Can I ask what makes you believe that? Why would someone be A-OK with sharing the previous six months of account transactions but balk at sharing the next six months of account transactions?
Because they have a mental model of what is inside the previous 6 months and can make a judgement regarding whether or not they are comfortable revealing that information, whereas the future 6 months could include purchases that they may not want to reveal for various reasons.
I also think many consumers would simply be creeped out by the idea that these companies can continue to maintain access to their bank statement for 6 months into the future, especially in cases where the consumer has a dispute or negative experience with the company. There are also some underwriting arrangements where companies could leverage future Plaid data to make decisions about how to treat a customer (e.g. monitoring bank balances so that rebilling a delinquent customer can be automatically rescheduled after a deposit)
+1 - co-founder of Plaid[1] here. Obviously biased, but would love to answer any questions anyone has about Plaid or interested in working with one of the smartest most humble teams out there. We're remote friendly and actively hiring for local talent in SF and SLC. Email is william at plaid dot com.
Hey! Co-founder of Plaid (plaid.com) here. We take privacy extremely seriously, I'm actually an early privacy.com user and major fanboy. Privacy only has access to the information needed to authenticate your bank account and make sure you don't get over-drafted. They don't use any of our income or assets products.
Hey! Co-founder of Plaid (plaid.com) here. RH does not pull your transaction history, RH is only using Plaid to authenticate your ACH accounts to make sure your actually the owner of the account and so you don't get over-drafted. They're using our auth and balance product, feel free to check out what information we return on our docs (http://plaid.com/docs).
Agreed there is no transparency around which endpoints are being used. There needs to be a screen that shows what data you’re providing like FB or Google login before you link anything.
Hey dawhizkid - co-founder of Plaid here. I can't give the rationale on why RH wrote the privacy policy the way they did, but I can guarantee you that they are not pulling transactional data. They're only using Plaid for the ACH authentication. If you'd like more insight feel free to shoot me a note at william at plaid dot com.
In general our approach is to focus on building things that 'only a bank can do' and if there are great existing solutions (ie: fraud, kyc, issuing processors) we let developers bring those solutions. We play nicely with all of them.