One of the big promises of software is composability. You can build rich, powerful experiences out of basic building blocks.

APIs add new things to the toolbox. For example: Treasury, which lets an app/platform store, move, and track a business’ money.

stripe.com/treasury
I've been a small business owner and can talk at length about SMB banking, and will later, but let's put on the software developer hat right now.

Lots of software talks about money, keeps records about money, does calculations about money, but can't *touch* money.
This is extremely frustrating when you're building SaaS apps for businesses, because you have total control over your UX right until your app needs to touch money... at which point all data about it lives in a silo you can't access.

So you generally push work to the operator.
For example, suppose you’re writing a business-in-a-box system for electricians, including an invoicing feature.

You need to be able to read bank transactions to reconcile. You probably can't. The owner can. So you ask the owner to do mind-numbing work a computer does better.
It sure would be great if your business customers had bank accounts you could actually introspect and operate on their behalves! You could just get the list of incoming payments and match against the invoices.

There is some software to write but it is not rocket science.
Stripe Billing goes to some crazy lengths to do this (virtual bank accounts, bespoke contracts with banking partners, etc); most SaaS companies offering invoicing as a feature probably shouldn't. You would want to spend your developer time elsewhere.
Stripe Treasury, now in limited beta, will allow software companies to provision money management accounts for their users, and then operate on those accounts like they expect to operate on data, servers, Stripe charges, or anything else you have an API for.
What’s the difference between a money management account and e.g. a standard banking checking account? As a user, not that much. You get a card to buy things with and get cash, and the ability to send ACH payments, bill payments, and the like.
The distinction is mostly implementation-layer concerns in banking-land.
It's difficult to envision what you can create given powerful primitives. Almost everything you see on a screen sits on top of NAND gates; looking at a NAND gate doesn't show you Twitter.

But let me speculate a bit:
B2B SaaS which deals with money, which is most of it, just got a whole lot more interesting, because it can directly operate on the money.
Take Shopify, for example. Shopify gives users an online storefront, and naturally needs to keep track of the total in the virtual register.
But with Stripe Treasury API, Shopify launched Shopify Balance, which lets them build a much better register. They always know the real total inside of it, not just what "should" be there.

They can automate its operations.

shopify.com/balance
And because of Stripe's global payments and treasury network, we didn't just make these capabilities *accessible* to developers.

We made it *better* for your users than many business bank accounts.
What does every small business care about? Cash flow. What's a top 10 customer support request for every business which sees funds flows, like Shopify?

"When do I get my money?"

Can you imagine needing to email Google to ask when that email that you know was sent will arrive?
If the money just arrived faster, there would be less angst for users whether it would arrive at all. Less tickets opened. Less questions you can’t usefully answer.

Why is money *so slow* and *so opaque*?
*sigh* That is a complicated topic, but at the end of the day, you're generally rate limited by the slowest rail between where the money comes in and where it goes out.

In the U.S., you’ll often be blocked on the ACH network. Fast compared to stagecoach; slow compared to email.
But with Stripe Treasury, money doesn't have to lag its way through the ACH network between a customer paying it and a business receiving it.

Stripe has an arrangement with the banks that ultimately hold the business users’ funds.
So when your software says "OK, disburse the money they've earned from the platform", it's in their account (and spendable!) on the same day.

(We are working on making that even faster by default. It’s not called HTTP 200 Check Back In An Hour.)
SaaS platforms are one use case for Stripe Treasury, but you can envision another one: novel fintechs, with different UXes, brands, and target business users, built on a core set of primitives.

Putting together fintech products is historically a pain in the keister.
Every significant feature you add requires an integration with a banking partner, often a *new* banking partner, often *several* banking partners.
That integration requires lengthy negotiations, bespoke legal work, approvals, etc just to unblock your engineering team.

Then your engineering team receives the spec, and the *real* fun begins.
We did away with most of that for Stripe Treasury, just like we did for Payments before it.

No negotiation required. No bespoke legal work. More of the necessary levels of complexity in touching money businesses depend on; less of the overhead.
And, of course, the care and attention to the developer experience that you'd expect from us.
A day may come when Stripe forgets what is was like to build software, when we ship a 400 page PDF file as the sole documentation for an API, but it is not this day.
So if you want to build a vertical fintech targeting carpenters? Offering payments in and out, a place to hold insured funds, and a card to spend them with?

You can build all of that on Stripe APIs now.
And if your users need financing? Snap in Stripe Capital for Platforms and we can facilitate access to loans based on their predicted future revenue through your platform. stripe.com/capital/platfo… (This also came out this week.)
And now, back to being an erstwhile small businessman who has had bank accounts for many years.

AAAAAAAARGH.
Small business banking has a poor UX, because of structural issues.

It is managed at most banks as an offshoot of personal banking, because the userbase is basically the same people who show up at the branch.

But the needs are quite different.
Banks specialize in one-size-fits-most products. The basic checking account you have is designed to cover more than 60% of the total population. It functions effectively the same for almost all of its users.
This kinda makes sense for individuals. Financial circumstances differ, but tend to rhyme: money in from a job or pension; money out to housing, utilities, debit card payments; some cash management.

(Narrator: This is not, in fact, an adequate spec for a checking account.)
But the needs of businesses are _wildly different_ from each other!
A small scale landlord cares quite a bit about mortgages and timely rent collection (and super-timely notice of non-payment), but rather little about payroll or expenses for consumables, and probably almost nothing for cash management.
A pizzeria, on the other hand, thinks it is inconceivable to make almost all the money on one day a month, spends most of revenue on payroll and consumables, and cares quite a bit about cash management.
These businesses deserve fundamentally different application-layer experiences from their banking. And they don't get them, because banks are incapable of offering hundreds of vertical software solutions.
(Just making the one-size-fits-most personal banking and mobile apps *actually good* is hard enough! It seems like we’re just getting there in the last 5 years!)
Who does offer hundreds of vertically-specialized application experiences? The software industry. Shopify specializes in e-commerce merchants and understands them, thoroughly. They don't sell to dentists.
Dentists have thriving ecosystems of firms that live and breathe every aspect of their practices.

So do graveyards. And hotels. And landlords. And spas. And tutors. And yoga teachers. And...
Why is software so varied but banking so… not? One reason is that businesses pay an awful lot for software, but pay relatively little for banking. Banking is a scale game.

Not enough dentists pay not enough dollars for banks to put software teams against dental practice UX.
But because a software company can address dentists by the nation, not by the square-mile-around-a-branch, and because they charge more, a software company serving dentists can reliably generate enough money to pay an engineering team.
Here Stripe acts as an aggregator: we can gather up *many* businesses attached to *many* software companies. These product teams understand their customers’ businesses *thoroughly*.

We can then take that package to leading banks. That reach is *very interesting* to them.
That is why Goldman Sachs, Citi, Barclays, and Evolve Bank and Trust partner with us.

A pizzeria can't walk into Goldman Sachs and walk out with a bank account.

A software company serving pizzerias could if they had, uh, a lot of dough.
But a material chunk of the software industry, that's a different story altogether.

And so our partner banks have made great products available, at pricing and terms that small businesses just don't usually get in direct banking relationships.
Take account maintenance fees. Please.

I know exactly how many times I paid the $14 account maintenance fee for my software businesses, ten years later. That’s how much I hated them.
I had gone below $X,000 in deposits (I was bootstrapped! Rent was due!) and hadn’t managed to spend at least $250 on the debit card because, whoops, mis-timed a billing cycle by two days.
(Being a bit older and wiser I probably should have just considered that $14 a cost-of-doing-business and spent my time on sales, not timing debit card transactions, but my emotional state at the time was closer to “Gah I feel like a chump.”)
We have agreed, with our partners, on a pricing structure where a SaaS company or fintech doesn't need to charge an account maintenance fee.
(As the software company, you *could*, because you control your pricing, but presumably you will make better choices, and your users will not say, ten years later, “I trusted you, and you made me feel like a chump. Six times.”)
How is this possible, and why didn't the banking system do it years ago?

One way to think of it is that banks have huge expenses to attract SMB deposits, including marketing campaigns and branch networks, and those drive the pricing of SMB banking.
The cost of *servicing* SMB accounts has gone down over the years, now that account statements are not calculated by highly-trained artisans, but the cost of *acquiring* them is increasing over time.

Nationwide advertising, branches, and sales reps aren’t as cheap as cron jobs.
Since the software industry is doing their own customer acquisition, and there is sharply less need for the branch network (itself more a sales tool than a servicing tool), some banks are happy to pass the savings back to Main Street.
There's obviously a lot more detail here (hosted onboarding flows, KYC and AML compliance workflows built for you, all accounts have deposit insurance, etc), but I have to end this tweetstorm somewhere.

I'm very excited to see what software people do with the Stripe Treasury.
Anticipating a FAQ: "Is this the product you were referring to here?"

No. This was my number two. You're welcome to your guess at the number one. (Though, who knows, I heard of a new project last week and might steal the zeroth spot for it.)

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with Patrick McKenzie

Patrick McKenzie Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @patio11

4 Dec
I suspect a great deal of peoples' annoyance with KYC isn't anything which is actually *required*, but is hitting poor *implementations* of it, sometimes with no clear path forward, which prevent them from doing the thing they actually want to or have to do.
This is often times because post-opening KYC is generally coming from exception handling in the financial system, and because (for the types of transactions likely to cause that in the lives of "typical people commenting about KYC") it is an edge case and not very designed for.
You often see (or worse, don't see) cracks in the abstractions, too, where you are dealing with someone passing a message from someone passing a message from someone passing a message from the underlying call site which generated the exception.
Read 4 tweets
2 Dec
Back when I was a Stripe user, my #1 ask for 3 years running was Capital. (Loans based on anticipated future revenue, which my SaaS company had in abundance while my bank account was feeling rather lonely.)

We have now made that capability available for our customers' customers.
Historically, banks were the primary point of interaction with the financial system for small businesses, and that interaction was largely mediated by humans.

Increasingly, the interaction is via an online platform, which provides a lot of the front and back office of the SMB.
If, for example, you run a platform which helps connect contractors and home owners, you likely have better data on their businesses' pipelines, revenue history, customer satisfaction, etc than any bank could hope to have.

But you can't easily just offer lending.
Read 6 tweets
1 Dec
There's an interesting microeconomics / finance / incentives angle here, where if this is your anticipation, you might decide to book the travel now and expect that providers will be lenient with cancellation/refunds if conditions worsen markedly over the next 6+ months.
Note that purchasing that option value is very much not a zero risk trade. For one reason, unlike financial options traded through a clearinghouse, you may be directly exposed to credit risk of the counterparty, which may not survive all possible futures.
Bonus lesson from credit card processing: the chargeback mechanism writes an option for the purchaser. The cost of it is bundled into the economics of credit cards, which are complex and involve multiple parties.

That option may have been mispriced in 2020 vis travel plans.
Read 4 tweets
30 Nov
This is an interesting article, by the Lying For Money author (my favorite non-fiction book of last few years), which without saying the word fintech explains quite a bit of the fintech market opportunity in the 2010s.
One reason banks were not innovating as quickly as one would expect on customer-facing experiences is they were spending billions and lots of management attention on internal core systems to be allowed to continue operating their businesses at all.
(“Core” has a specific and idiosyncratic meaning in banking; I didn’t mean that one specifically.)
Read 4 tweets
30 Nov
Today's new phrase in Japanese, regarding a company's explanation about policies: 支離滅裂, which appeared in a text from my wife and which I couldn't read. This does not generally suggest the word will be positive.

Having checked the dictionary, apparently it means this:
As long as I'm on fun linguistic notes, let me note that the only word I've seen the third character in frequently is 撲滅 (bokumetsu, exterminate), which was part of the tagline for the Stamp Out Piracy campaign at movie theatres before the feature rolled.
And in checking that I realized that for several years I've been mispronouncing that word as "bakametsu" (爆滅, to slaughter with explosives), which explains a number of previously mysterious negative interactions during discussions of IP law and piracy with coworkers.
Read 5 tweets
29 Nov
I overwhelmingly agree with this.

Translation is a creative act, and it is a hard one, involving a balance of art, respect for the logic and of the original, respect for the meaning in the target language, and a lot of questions for which there are no universal answers.
One example, relevant to the topic discussed in the thread: To what extent should a Japanese document translated for an American audience convey that it was definitely written originally in Japanese.
There are some texts where you could produce two faithful translations of the original, one which utterly sandblasts the performance of culture from it and which will be understood, and one which maintains the performance and will be impenetrable to the target audience.
Read 5 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!

Follow Us on Twitter!