Zac Townsend

We have some news upcoming about Standard Treasury. But before that...

Almost every week, I get thank you notes for publishing our YC application. It is one of my most viewed blog posts ever. Those notes remind me over the large, supportive community of entrepreneurs. It's been one of the more heartwarming lessons about running an early stage company: there is a supportive conspiracy between all founders against the world (and, well, investors in particular).

That support — of lessons learned, or how to improve your pitch, or tidbits on investor's quirks, or how to manage psychology, or how to fail — is often private but is sometimes public. Whether its about a second seed round, laying off a large part of the team, or selling your company, many founders are quite generous about passing their learnings forward, good or bad.

One thing I found very useful while fundraising was to look at published fundraising decks, both successful and unsuccessful (Mixpanel, Dwolla, and LinkedIn come to mind on the successful side). Since almost all of the "ideas" from our deck have published elsewhere, either on our website or in the Standard Treasury as Bank post, we decided to publish our Series A deck. It's imperfect (slide 7 is inaccurate, we got asked a thousand times to explain slide 14 (it's in '000s), the appendixes tend to be too long, we did not focus enough on the already built product), but Dan and I think it might be instructive for others.

In time, we'll be able to talk more about this process and the things that did and didn't work. Lots of lessons learned. To start though, here is the deck. 

(This started as an email to the Standard Treasury team to summarize the many conversations that my cofounder Dan and I had with them over lunch, dinner, coding, and a ton of product discussions. The team thought it made sense to share it publicly.)

I often get asked to tell the story of Standard Treasury: Why are we building it? What is our vision? How did we come to this thing over all others?

When asked questions like that one, I think it can be easy to fall into simple narratives or platitudes: we are revolutionizing banking, and have been, since day one! I'm not exactly sure what that sentence means, and nothing worth doing actually comes in a flash of genius. Certainly not by folks like us, who have always gotten on in the world through persistence first, and smarts a distant second.

The bigger problem is that I never have the time to tell the folks who ask the questions all that is on my mind, so I ended up telling them bits and pieces. This [blog post] is designed to tell much of the story although I still haven't captured it all by any means.

The Underbanked and Engineering Financial Operations

For me, the genesis of Standard Treasury was based in the two experiences I had in the year before founding the company.

The first was when I was working in public policy and civic technology in New York City and Newark. Particularly when I was working for Cory Booker and staff in Newark, I became curious about underbanked people — or the problem of financial empowerment as it is sometimes called. I talked to a ton of people about their use of payday lenders and check cashers. What I found was surprising to me (in my ignorance): most underbanked people or small business owners are familiar with banking products, their use, and their relative value over the options they were using.

So, why didn't they use banks? The answers fell into one of two buckets. The first is that they wanted lending products they couldn't get, since the banks considered them too much of a risk. The second was that banks just wouldn't offer them other products even if they had nothing to do with lending. I found this second answer rather perplexing, so, I went to talk to a bunch of banks. What they told me was simple: it cost money to maintain bank accounts — serious money — and if you weren't going to cross-sell customers something, it didn't make sense to bank them.

That surprised me. The more research I did with banks, the more I realized that it was their legacy technology that led to their cost structures. Cost structures that prohibit them from banking some people. In essence, there are folks that banks don't market to and avoid banking because the banks' business models makes those people unprofitable customers.

The second experience was when I was working at Stripe. I won't go into a huge amount of detail here — I try to be careful about my nondisclosure requirements. Having said that, financial operations is a serious engineering challenge at Stripe (see CTO Greg Brockman's Quora answer and the section on financial operations). While working there, I got to see, firsthand, how difficult it was to operate in systems, protocols, and technologies that were designed and built in the 1970s.

Starting Standard Treasury: Commercial Banking API

Standard Treasury started because we experienced the difficulty of working with banks firsthand. Way before the company started, Dan and I had been thinking about why ACH is flat-file driven, slow, and seemingly from a different technological age. Having worked on issues of the underbanked, I realized the real-world impacts of legacy technologies, and working at Stripe highlighted how much of the credit card system was driven by similar technology. The same ideas were highlighted for Dan when he was working on pre-paid cards and stored value.

Standard Treasury was born.

We were focused on the problems we knew firsthand, and used the cases we understood best from our friends. In the early days, we talked to nearly one hundred folks about their banking experience. Some were running small companies, others were the treasurers of Fortune 500 companies. They all said roughly the same thing: "The technological interfaces around my commercial banking experience are terrible and limit my capabilities." Many mentioned Twilio, Stripe, AWS, and Heroku as models of what they wish their banks would be: technology platforms providing services.

From that, we started working on a white labeled commercial banking API platform. This first product was clear to us: companies, big and small, want to build financial functions — primarily on information about their accounts and cash payments — directly into their applications. In the coming months, we will finally be able to see the result of all that work as more than our Make Believe Mutual demo site: after a series of proofs-of-concept we have the option to launch our first, full production platform.

Developers, with a bank account at the bank in question, will be able to go to developers.[bankname].com and use an API platform, developer portal, and SDKs in half a dozen languages to interact with their bank accounts programmatically. Hopefully, a number of our other proofs-of-concept projects will convert into full production platforms with some of the biggest banks in the country and around the world.

Taking Steps Beyond V1.0 of the Commercial Banking API

From there, some product expansions in commercial banking will be inevitable: more information reporting, more cash payments, liquidity management via API, and other banking functions like foreign exchange and lending against receivables (factoring).

The most exciting thing that we've built, however, is an OAuth service that allows commercial customers — some of whom will have no idea what an API is — to use the bank's authorization service to delegate access to the API to third-party developers. With that service, developers will be able to build apps that access their financial information and cash payments, just like Facebook Connect allows granular, secure access to the social network. We hope that folks like Xero and Intuit will build apps, but we are starting to get to the real goal here: allowing developers to think of banks as platforms.

Broadening the Vision

In investor meetings and in candidate pitches when we got into YC, we made the idea of Standard Treasury bigger by abstractly focusing on the idea of bank software being broken. We did not really know what that meant. It was a hard-to-unpack intuition from the state of online banking, rather than something we really understood in particular. Something was wrong. We would find it, and we would fix it.

Over the last year, though, we have learned a great deal about the particulars. We have picked the brains of bankers; fund managers; treasurers of big corporations; startup founders working on finance; startup founders trying to avoid finance who, nevertheless, touch it more than they'd like; executives at our competitors; academics; journalists; experts and leaders from card networks and credit card processors; folks concerned about financial access like the Gates Foundation, Cities for Financial Empowerment, and Omidyar Network; and many more. I read the Financial Times and books on obscure parts of the financial system every day. Dan and I also went through Silicon Valley Bank's and MasterCard's joint product accelerator, Commerce.Innovated, and the NYC FinTech Innovation Lab where banks choose the companies in the program which they are going to mentor. The banks that chose to mentor us were Goldman Sachs, Credit Suisse, Morgan Stanley, and Deutsche Bank, who have been very helpful in highlighting areas of expansion for us.

In that deluge, several things became clear. First, we learned that bank software is a very big market. Even bigger than the number I made up with some back-of-the-envelope math for my YC Demo Day pitch!

Second, we learned that the market is dominated by large public companies that no one in Silicon Valley is aware of, much less really competing against. Banks, almost universally, have bad things to say about the technology and the pricing schemes of these vendors.

Third, we learned that API Banking is much more than a cool feature for banks to have for corporate clients: anywhere that customers interact with their banks is a place that a bank might imagine a well-built API. Banks have approached us about building white-labeled API platforms for lending, sales and trading execution, broker/dealer settlement and exception handling, prime brokerage, card processing (acquisition and issuing), custody accounts, fund administration, retail banking, private wealth banking, repo and other money markets, trade finance, know your customer and anti-money laundering procedures, risk management, and more. (What keeps me up at night is the possibility that we're passing up opportunities by not scaling much bigger, much faster.)

Fourth, we learned that as we build interfaces for external customers to access legacy systems, banks are facing internal and external pressures (e.g. stress test requirements) to build cross-functional interfaces for their own use. Some of the biggest pain points that banks face is talking to their own internal systems.

Fifth, we learned of this platform's potential impact on the world. Every week Dan and I get referred to folks who are starting financial technology companies or not-for-profits. None of them want to be in our business, but nearly every one of them would be able to make their work easier, faster, and better if banks used our products. Despite all that is happening in fintech, there is a lot of pent-up developer and technological potential — potential that would actually help banks, which their unwieldy technology keeps them from enabling.

Banking Today and Tomorrow

There are two types of common innovations happening around financial services: tools that provide some gateway into the financial system, but abstract it away (like Stripe, WePay, Plaid, Spout, WealthFront) and shadow-banking alternatives to a common financial product (Lending Club, OnDeck, Upstart, LendUp, ZestFinance).

We are doing something different: we are working to build the next generation financial infrastructure by building products, interfaces, and developer tools directly.

No matter what changes will happen in the next 10-20 years in finance, we believe that: (1) Banks are here to stay. Banks will exist in the future. The center of the financial system will include banks. (2) Banks need 21st-century technology. (3) Standard Treasury is uniquely positioned as a Silicon Valley startup focused on banking infrastructure to sell to that need.

Enabling the Next Generation of Commerce

So why does all this matter? Well, partially, it matters because I already have friends who are building mobile apps for underbanked folks that are built directly on abstractions that we're helping them with. That really matters to me; it's a huge part of what originally got me into this business. But beyond that, at a more abstract level, we care about building the financial infrastructure because banks are at the center of commerce.

Sometimes, it is easy to think that banks are an end unto themselves and all they do is extract wealth through speculation or innovative wizardry to screw their clients. They do far more than that, too.

Financial and payments systems — including the money markets, foreign exchange, credit cards, ACH, CHIPS, FedWire, debt markets — are all designed to facilitate trade. However, trade is hampered because, although we've entered the Internet age, the technology at and between banks is often in the Sputnik age.

Standard Treasury aims to improve the ways that companies and households do their financial business. We hope to enable developers of all types to build the next generation of tooling on top of banks. We want to improve the ways that clients interact with financial institutions; financial markets; financial market utilities; and payment, clearing, and settlement systems. We build systems to increase global trade, global commerce, and maybe global GDP.

That is an audacious goal and comes with a core thesis: if we improve interfaces inside banks, between banks, between banks and customers, between banks and (technologically sophisticated) resellers of financial services, and between banks and other counterparts, then we can change the very nature of trade and commerce. We can reduce friction. We can lower transaction costs: both the literal costs of transactions and just the pain that exists in the financial system. Ideas that were impossible become possible. Businesses that didn't make economic sense suddenly do. People that were unbanked before suddenly become bankable customers for someone.

Our goal is to make it easier to run businesses — online or off — in the United States or around the world. And as we serve as a data, abstraction, and tooling layer between different banking systems and between different parties that are doing banking, we become a permanent feature of the banking system. That last part is good for us and our investors, sure, but I hope it's also good for the world.

What's next

Through Dan's prodigious marketing and sales efforts, we have come to own a lot of "mindshare" around API banking. That ownership allows us to dream what I've written above: to build the coming generation of financial infrastructure.

We have also done something that is nearly impossible: we are a seven-person company that is being paid by a bank for a product that is loved by nearly everyone we've shown it to. Tons of feedback, yes. Tons of feature requests, yes. But our potential users, nearly universally, loved its execution and, perhaps, more importantly, its potential.

Thank you, all of you, for helping to take this crazy idea and make it a reality.

It is hard to hire people. It is very hard to hire great people. Our core team is amazing. I hope that by telling the stories of how we hired our team, haphazard as they are, others might get a sense of how to put together a good team.

Yesterday I told the story of how Standard Treasury's founders knew each other and today I am telling the story of hiring our first three employees. With that story I share five lessons learned about hiring: get your message straight, start now, do whatever it takes, be aggressive, and create a process.

I have talked to a number of YC founders that are at much later stages than us. They admitted they had a terrible time hiring at the beginning. They just didn't have access to top-tier talent. They didn't necessarily know at the time what top-tier talent was. Some didn't go to fancy schools and didn't have great networks. Some did YC when it wasn't what it is perceived to be now.

Once money is no longer your biggest problem, hiring is. They succeeded through grit, persistence, and a healthy willingness to fire people when they needed to.

We made offers to our first two hires before we quite finalized bringing Brent on as our third co-founder. As two only quasi-technical co-founders Dan and I have just gotten lucky at their quality and we have learned some lessons along the way.

I have a good sense of whether someone is an asshole or not, whether they can break out and plan tasks well, whether they get or are interested in our business, or whether they're completely full of shit technically. But, whether they can abstract classes well, can deliver high-quality software, can keep to our bank-imposed deadlines without sacrificing too much, or can write good test coverage...well, I'm flying blind other than that I know enough to ask the questions and see if my full-of-shit-meter goes off.

One thing we did have though was a great message. We have a big idea that scared most people away, and a network big enough to run references on almost everyone that came our way.

Lesson 1: Get your message straight. Think about how to message your company as much to candidates as you do to customers. We realized that Standard Treasury is potentially a big business but all the challenges were in relatively boring, if complex, topics like building against legacy interfaces and presenting unified APIs despite those crazy backends. We embraced the boringness and made it a strength: you can work on a big serious problem or with the others guys. To us, having a boring idea made it so the excited candidates were genuinely excited.

As one of my co-founder says, I know enough to be dangerous in all things, but it's clear to me that if you ran the simulation a thousand times, we likely wouldn't have gotten the outcome we did very often. We hired three great engineers to our core team without doing any technical screens.

The Infrastructor

One of those two initial offers was to Mike Clarke. Mike was in charge of infrastructure at Disqus, where he helped to serve more than a billion 'uniques' a month.

Mike and Dan knew each other from their days in Chicago (having been introduced by the great John Fox), but stayed in touch when they both moved to San Francisco. They ran into each other a lot, on the line for Senor Sisig (a food truck that's often on 2nd and Minna), and Dan would always say "When I found my company, I'm going to hire you!" Mike thought Dan was crazy. Dan had no idea just how good Mike was.

I looked through my emails and found that we started the conversation by Dan emailing Mike the TechCrunch launch article with the subject line: "Leaving disquess and joining Standard Treasury." Correct spelling wasn't critical to Mike.

A few long conversations later, Mike joined the team. Mike has ended up being the perfect early-stage engineer: a great coder, dedicated, thoughtful, fast, willing to take on anything, and with a skill set that has been critical to launching within banks.

Lesson 2: Start now. Always be recruiting. In the case of Mike this meant even before we started the company. You know who your best engineering buddies are. You know who you can work with every day all day. Start recruiting them even before you start your company. Maybe even years before. Recruiting takes time.

The Bank Integrator

Keith Ballinger proved easier to find, but, we were even less thoughtful about whether he had the right technical chops. We fell into him being a killer engineer. Keith worked for many years at Microsoft, including as an original core contributor to C# and .NET (although no one hates what it's become more than Keith) and then worked at a series of startups. He's our go-to expert on crazy enterprise software. He and I often handle all our bank integration meetings together.

Keith applied through Hacker News' jobs page along with a couple hundred other people last summer. Dan and I both met him once or twice. He seemed competent and didn't set off any of our red flags. We did a few reference checks that came back positive, but never did a technical interview. Then we offered him a job. I don't suggest that as a model for hiring employees.

Lesson 3: Do whatever it takes to find great candidates. Posting on job boards creates a lot of resumes and a lot of work. It isn't efficient but finding a needle in the haystack is worth it. Great engineers multiply your productivity and value exponentially, so spend time doing whatever it takes to find great people.

The Platformer

Last, but not least, Jim Brusstar rounded out our core team. Jim's the only one we hired who we knew was good — Brent had worked with Jim for years at Facebook. After Jim left Facebook to work as an engineering lead at Sidecar with his college buddies, he and Brent kept in touch. And when Brent told Jim he was founding a company, Jim was eager to learn more about the idea and meet the team. Jim joined thereafter.

Jim is the core author of our API infrastructure and is every bit as fanatical about code quality as Brent. Which makes sense, since he's the first person we hired based on knowing whether he was good or not — and he's been great. He keeps us all focused on the question of what will developers — and not necessarily our paying bank partners — want in the API. He's critically focused on building an excellent product experience and rounds out our core team perfectly.

Lesson 4: Be aggressive. Reach out to everyone you would love to work with. No matter how senior or junior. No matter how comfortable they may seems. You never know. Think through everyone you've ever worked and would like to again. Reach out to them as soon as you start your company. Some great candidates will jump, like Jim, others will take time but either way you're letting people know you're looking and you're setting people up to think of you when they do want to jump.

Hiring Moving Forward

Now, hiring is much more of a process. We've iterated through a ton of different technical questions and screens. With almost every candidate, we use the same process: a 15-minute intro phone call, followed by a 45-60 minute coding screen (usually on a call with a virtual whiteboard, but sometimes in person), then a 4-hour coding challenge / homework assignment, concluding with a 4-hour on-site interviews. The top of our funnel had hundreds and hundreds of resumes, we've done dozens of coding screen, we've had seven or eight full on-site loops, and we've made two offers.

Lesson 5: Create a process. Even at a small startup, process is important. We are inundated with applications that need to be sifted through and lunches with old friends. The only way one can manage it and feel like one is being fair and polite to every candidate is to create a process. A process allows you to move quickly, give people feedback, and seem like you have it together.

We've also been able to articulate, make known, and get a lot of feedback, on our values, which seem appealing to the types of candidates we find attractive:

• Excellence. We are building a team of great women and men who work hard, have a passion for perfection, and don’t tolerate bullshit.
• Candor. We practice internal transparency, and are candid about our finances, business development, and planning processes.
• Quality. We build bank software - our motto is more “slow and steady wins the race” than “move fast and break things”. Our critical technical values are security, reliability, consistency, maintainability, and craftsmanship. We emphasize tremendous attention to detail and build software that lasts.
• Collaboration. We use Phabricator and support each other with code reviews. We have a healthy culture of debate without argumentation.
• Entrepreneurship. We encourage people to set their own direction. We are looking for senior engineers who can lead product decisions. All engineers are able to suggest, research, and lead architectural changes, contribute to, and suggest, revisions to our road map, and create new coding guidelines and have them enforced.

If those sound interesting to you, or if you're just interested in joining a place that (by sheer dumb luck) has a great core team, then check out our jobs site.

The number one way that startups in Y Combinator fail is through founder disputes and divorces. It often turns out that people cannot work together or one of the founders can't really work on startups at all. So picking who to work with is one of the most critical things you can do to ensure that your startup will get through the early stages.

Y Combinator applications just opened for this summer's class. It seems like a good time to talk about how Standard Treasury's co-founders knew each other and laid the foundation for sticking together, raising a seed round, launching a product, and building a good team.

My two co-founders and I know each other in much different ways that basically mirror the two ways one should find co-founders. With Dan, we have been friends for over a decade. We have discussed founding a company together for years. We know each others habits, strengths, and weaknesses inside and out. We knew we could work together.

With Brent, we knew each other for only months before we started working together and we were constantly assessing whether we could work together, figuring each other's style out, and ultimately deciding we could be partners carefully and over time. We vetted each other in-person and through friends and professional contacts. We came to know we could work together.

If you're going to found a company with someone, I'd suggest having one of these two stories: old friends or careful decision. I have never seen anything rushed or careless work out well for the startup or the team. I have never seen it work out just because folks can agree on an idea. Startups are more hectic and trying then that. In that way, the story of how I know Dan and Brent can be instructive to the ways one should know and vet their partners.

This is the first of two posts on building our team at Standard Treasury. The second post will be on our first three engineers. Building a team is the most important priority of a startup. With a great team, one can get through most troubles. With a bad team, even the best startups can fall apart.

Two Argumentative, Balding Friends from New Jersey: Dan and I

Dan and I met at Harvard Summer School in 2003. We were not instantly best friends. I remember quite vividly the first day of our first class, Introduction to American Government. Dan was then quite similar to how he is now, at least in this one respect: we met because he walked into the classroom and, without any compunction, began introducing himself to every single person in the room. I found it strange then and although I still find it strange now, I at least can see its utility. It is why Dan focuses on business development at Standard Treasury.

I was particularly annoyed though, when I showed up to my second class, Introduction to Political Philosophy, and there Dan was, introducing himself to everyone in that classroom as well. We were the only two students who took these same two classes.

Despite whatever feelings I might have had that first day, in retrospect, it seems obvious that we were going to have a full and long-lived friendship. We were both from New Jersey, and then, as now, we have a mix of tough-guy go-fuck-yourself, sarcasm as humor, insatiable curiosity, intellectualism, and ambition.

I have this theory that lots of founders have childhood trauma (or, at least, difficulties), that motivates them towards the implausibly difficult task of building a startup.[1] A part of my deepest friendships come from a common, shared understanding of something difficult: in Dan's case, the tragic death of his father and serious injuries to his mother in a car accident when he was an infant, and in my case, my mother's alcoholism and disappearance from my life for ten years.

The important point here isn't the particular personal details of our childhoods, though. As Dan and I got to know each other that summer, we bounded over our similarities in affect, goals, and histories. We spent a lot of the summer together, studied together, explored Cambridge and Boston, and became good friends.

Harvard ended but geography kept our friendship alive. We only lived thirty minutes apart in New Jersey. We would hang out, from time-to-time, throughout our senior year, and like all teenagers of that era, we spent a lot of time chatting on AOL Instant Messenger.

It's hard to understate or understand the intensity of our friendship from there on out. We went to different colleges in different time zones. We saw each other maybe twice a year in person. But Dan was among five or six friends that I talked to nearly every day (and I feel bad that I don't have a reason to write blog posts about them all!), and one of my closest friends.

We usually simplify our friendship by referring to the month we spent together in India in 2006. It's a good synecdoche. I had a fellowship from Brown in the summer (I think I successfully had them pay me, to do what I wanted to for every summer), and Dan was traveling on to Nepal and Tibet with a UChicago group. We visited Delhi, Agra, Jaipur, and Varanasi together as poor college students. We got very sick together, rode elephants together, visited the Taj Mahal together, got lost together. It was fun, but, at times, stressful. We learned a lot about our friendship through that sort of travel. We figured out, I think, that we could work together.

After college, Dan moved to San Francisco, I moved to New York. We pursued what appeared to be quite different career paths. Dan in tech, me in government. But we're both passionate about many subjects and my interests moved closer and closer to data science and civic technology over time.

Dan and I had spoken many times about founding a company together. Whether it was the naive thoughts of two sixteen year olds or the more mature (I hope) reflections of two old friends separated by thousands of miles, it has been often in our minds. So, when I decided that I wanted to move on from the Mayor's office in Newark, NJ, I decided to pursue my interest in technology more directly, by moving out to San Francisco, working at Stripe, and being closer to my old friend Dan.

That inevitably lead us to applying to YC, getting in, and starting Standard Treasury.

Being old friends is one model of finding your co-founder but another is meeting each other through trusted friends and deciding you can work together after getting to know each other quite intensely. That's the story of working with Brent.

Bringing on Brent: Third Co-Founder and CTO

The cornerstone of our team at Standard Treasury is our third co-founder and CTO: Brent Goldman. He joined Dan and I during Y Combinator. He came highly referred from a friend (and many others), studied computer science at Caltech, and worked at Facebook on Platform for four and half years.

If you know Standard Treasury today, you know Brent. Brent and I work together on every product decision, as PM and EM, while Dan sells banks.[2].

Dan and I were first introduced to Brent in February 2013. A friend told me that Brent and Dan were his two smartest friends and that they were both thinking about starting companies.

When we first met, Brent was kicking around some great ideas and, in fact, had another potential co-founder he was working with on them. Dan and I had thoughts about Standard Treasury (then without a name) in ways that were much like our original YC application, which was filled out around the same time.

But, when we met in February, we were all casual. We hadn't incorporated Standard Treasury. Dan was still at Giftly, I was still at Stripe, and Brent was working with another co-founder. It seemed then that the timing would not work out well for the three of us to work together, although we all ended up liking each other a good bit. At the time, I remember being pretty sure that I would be at Stripe for four years!

Despite Brent’s immense interest and experience in platforms, in these early days we were just feeling each other out (and aligning calendars - including a month-long trip to New Zealand). Brent tried to sell us on some of his ideas, but Dan and I knew what we wanted to do as YC had already offered us a YC interview on the idea. I'm not sure we could sell remaking commercial banking well at the time — it is boring to the uninitiated.

What we found, though, was a lot of group chemistry — what we've come to call "founder chemistry." Our skills complemented each other, and ideas were flowing. The only issue was that we didn’t know each other and we didn't know if we could work well together long-term. Founding a company together is like a serious relationship and this was just the first date.

Over the next couple of months, as Dan and I left our respective jobs and got in to YC, Brent, Dan, and I met up every couple weeks to expand on our ideas, swap war stories, and discuss philosophies about what kind of company we wanted to run. Over time we realized that we could work together, and that we could found a company together.

So we joined forces.

Brent fills out our skill sets and together we're all well-complemented. I often joke that on almost everything (technical skill, financial knowledge, desire to talk to investors, ability to write clearly, attention to detail, etc.), that between the three of us, two of us are always at opposite ends of the spectrum, with the third acting as the mediator. It works well — it's just the right level of tension and conversation between us.

Most importantly, Brent puts engineering excellence above almost everything else and has the experience in shipping code and mentoring engineers to back it up. He's instituted a thorough code review process, sets the technical direction, and works with everyone to build sustainable, maintainable systems.

But, despite his perfectionism and attention to detail, he's also a pragmatist who will do whatever it takes to get things done — whether it's re-prioritizing or cutting features, accumulating technical debt (the right kind, with a sound plan to pay it off), or leading the charge to the long hours necessary to meet a tight deadline.

Brent is a force multiplier for engineering productivity and has infused our company with the engineering-focused culture we always knew we wanted. We lucked out in finding the right co-founder to help us build it.

Growing the Team

Just as we were formalizing our relationship with Brent, we finalized two more engineering hires. They are both dedicated and productive, and both snapped to the engineering culture Brent wanted to build. Then Brent brought in an old colleague from Facebook to fill out the core team. It's been the six of us together until our first new hire last month. We've found that we not only have an amazing team but one that is very cohesive.

In my next post I'll talk about how to find a team, what kind of team one needs to build for a successful startup, and how we did it at Standard Treasury.

[1] I even have a half-written, unlikely-to-be-published blog post on this topic, and how much I validated it through my dozens of close friends in YC. It is a hard thing to write about because it's deeply personal and it opens you up to a common line of attack: well, I had or have it worse.

[2] The division of responsibilities and founder relationships is another planned post.

Below is the application that Dan and I sent in to YC. Our business model has changed a ton since then and I'm not particularly worried about folks beating us on our combination of technology, relationships, execution and payments/banking knowledge.

Also see my post from Tuesday on our story of applying to YC and my post from yesterday on application advice. Next week I'll share some of the highlights of the summer from getting in to demo day.

Your YC username:

zt

Company name:

bedrock (we're working on it)

Company url, if any:

Phone number(s):

[Redacted].

Please enter the url of a 1 minute unlisted (not private) YouTube video introducing the founders. (Instructions.)

[Redacted].

YC usernames of all founders, including you, zt, separated by spaces. (That's usernames, not given names: "bksmith," not "Bob Smith." If there are 3 founders, there should be 3 tokens in this answer.)

zt dkimerling

YC usernames of all founders, including you, zt, who will live in the Bay Area June through August if we fund you. (Again, that's usernames, not given names.)

zt dkimerling

What is your company going to make?

We are building APIs for commercial banking services by building on top of multiple large banks.

If someone needs advice they can call Goldman. If they just need to transact then they can use one of our APIs. We will build commercial banking middleware that will sit on top of banks just like Twilio sits on top of multiple phone carriers. It is much easier because we'll have (mostly) RESTful APIs with good documentation, etc, and (if we choose) cheaper because of bulks rates.

1) Delivered programmatically, using good APIs - Anything transactional shouldn't involved a human being. Most banks suck at technology and admit that. They're excited to have us resell their services.

2) Narrow to start, but ultimately broad services - We want to abstract away the pain of dealing with banks for transactional services like ACH, F/X, wires, factoring, short-term loans, etc, just as Stripe, Braintree, and others have done for getting a Merchant ID. We are starting with ACH and F/X as foundational products.

3) Multiple banking partners - We're willing to endure the pain of setting up commercial contracts with many banks and then offering the transactional services (via API) in an intelligently routed way. We've gotten verbal agreement from Wells Fargo, and are pretty far along with JPMorgan and Capital One. Will start with other banks shortly.

For each founder, please list: YC username; name; age; year of graduation, school, degree and subject for each degree; email address; personal url, github url, facebook id, twitter id; employer and title (if any) at last job before this startup. Put unfinished degrees in parens. List the main contact first. Separate founders with blank lines. Put an asterisk before the name of anyone not able to move to the Bay Area.

zt Zachary Townsend 27 2009, Brown, AB, Applied Math, Economics ztownsend@gmail.com zactownsend.com http://www.facebook.com/zactownsend @ztownsend I work at Stripe, mostly on Risk

dkimerling Daniel Kimerling 27 2008, UChicago, AB Political Science, AM International Relations, (Also half-way through UChicago Booth MBA) http://www.facebook.com/dkimerling @dkimerling COO, http://www.giftly.com/

Please tell us in one or two sentences about the most impressive thing other than this startup that each founder has built or achieved.

ZT reorganized child welfare investigations in New York City. He got tons and tons of data, wrote R code to analyze it, set up ethnographic research conducted by his team, etc. He sniffed out details, wrote a report, and then helped implement the changes to a staff of 2000, and a budget in the tens of millions.

Dan built Giftly, particular the proprietary stored value product, from a regulatory, legal, risk, etc, perspective.

Please tell us about the time you, zt, most successfully hacked some (non-computer) system to your advantage.

When I started in Newark, I didn't have a computer or an email, and City Hall didn't have wireless. So I tracked down one of the wireless networks I could find - owned by a bails bondsman close to the court, and negotiated with them for their wireless password.

I once spent hours looking at floorplans and historic housing lottery data so that my roommate and I could pick a HUGE double with our own bathroom despite having a terrible pick at Brown.

Please tell us about an interesting project, preferably outside of class or work, that two or more of you created together. Include urls if possible.

http://deciens.com/ We raised the money, we have made investments. We have been to YC demo days and invested in Keychain Logistics.

How long have the founders known one another and how did you meet? Have any of the founders not met in person?

We've known each other since we were 16, when met at Harvard summer school.

Why did you pick this idea to work on? Do you have domain expertise in this area? How do you know people need what you're making?

We started by thinking about ACH, which is a problem that Dan actually had in his work. Zac sees how hard it is for even Stripe to deal with Wells Fargo on F/X, wires, etc.

Dan knows a ton about payments. Zac won finance prizes @ Brown. We both want to disrupt banking and have been talking about it for years.

What's new about what you're making? What substitutes do people resort to because it doesn't exist yet (or they don't know about it)?

When most businesses wants to do something financial they have to call their bank and talk to a person - except for getting a MID. That doesn't make sense. Getting a wire, as an example, often involves twenty minutes, a painful conversation, and $30. Even non-quant hedge funds needing to convert EURO to GBP have to pick up the phone and talk to a bank's trading desk.

No one has built developer friendly bank back-end processing, so you have to deal with banks, which overcharge, are slow, and are not developer friendly. Wells Fargo, for example, does offers an API which costs more than their other options and, well, is not very good.

Who are your competitors, and who might become competitors? Who do you fear most?

Possible competitors: Square, Stripe, Braintree, Wells Fargo, JP Morgan, Bloomberg, Intuit, PayPal

Banks cannot innovate on technology. A senior exec at JPMC told us that even if building good APIs was a Jamie Dimon priority it couldn't get done before 2017.

Commercial banking broadly - including every service we're imagining other than ACH (F/X, Wires, Factoring, Lending, Account Creation/Deletion, etc) - is not something that the innovative payments companies plan to provide to others, although they're all services they, themselves, need. Stripe, for example, is trying to make payments work on the web. We're trying to make commercial banking work in the world. They're both trillion dollar problems, but they're different.

So, who do I fear most? I fear regulators the most. Banks can't beat us on technology but we might be so successful they beat us with the law.

What do you understand about your business that other companies in it just don't get? People who run banks don't care about providing high quality technology services, and the people who care about technology don't want to work with (or buy) a bank. Schlep blindness, as it were.

Also, there is great power in abstracting away thinking about your particular bank. Take ACH: since we are willing to suffer through forming eight banking relationships, we can provide next-day payouts to 80% of checking accounts in the US. Everyone else can only do next-day payouts on their one bank.

How do or will you make money? How much could you make? (We realize you can't know precisely, but give your best estimate.)

We make money on transactions.

For a (very, very) rough guide, profits at ten biggest banks last year were $120b. Let's call 50% of that transactional/FICC/pure commercial banking as we define it.

As for TAM, SAM, SOM, using big-O:

Total addressable market: O(100s of billions)

Serviceable available market through APIs: O(10s of billions)

Share of market: O(10s of billions)

If you've already started working on it, how long have you been working and how many lines of code (if applicable) have you written?

Pre-development. We've incorporated. I'm still at Stripe. Dan's still at Giftly. It didn't make sense to start until one of the banks signalled a willingness to sign a commercial agreement as their was nothing to integrate with. Ready to start now. Raising money because of non-trivial commercial and regulatory costs. Far along with recruiting the rest of the early team and considering raising a seed round.

How far along are you? Do you have a beta yet? If not, when will you? Are you launched? If so, how many users do you have? Do you have revenue? If so, how much? If you're launched, what is your monthly growth rate (in users or revenue or both)?

We're far along on regulatory/commercial contract/legal stuff. Once we have that settled, there is a lot of backend, unsexy stuff to do to make it as pretty/smooth as we'd like: settlement files over SFTP, testing required by the banking partner, automatic underwriting built on Microbilt/LexusNexus/Iovation, etc, and then launch.

If you have an online demo, what's the url? (Please don't password protect it; just use an obscure url.)

No online demo yet. It might be awhile before we have a dashboard and mocking up a fake API for you doesn't seem worth it.

How will you get users? If your idea is the type that faces a chicken-and-egg problem in the sense that it won't be attractive to users till it has a lot of users (e.g. a marketplace, a dating site, an ad network), how will you overcome that?

Working the network, undercutting others on price and (especially) ease, directly reaching out to every startup that needs banking services beyond payments that exists or is founded for traction.

We've focused our user research on three customer segments: (a) Corporate treasury departments (a heretofore undisrupted part of most enterprises) (b) hedge, private equity, and venture funds (minus quants/HF) and their back offices (c) technically inclined SMEs and startups who aren't served well by big banks.

If you're already incorporated, when were you? Who are the shareholders and what percent does each own? If you've had funding, how much, at what valuation(s)?

[Redacted]

If you're not incorporated yet, please list the percent of the company you plan to give each founder, and anyone else you plan to give stock to. (This question is as much for you as us.)

If we fund you, which of the founders will commit to working exclusively (no school, no other jobs) on this project for the next year?

zt dkimerling (we've envisioning this being a, uh, five-ten year project at least)

For founders who can't, why not? What level of commitment are they willing to make?

-

Do any founders have other commitments between June and August 2014 inclusive?

No.

Do any founders have commitments in the future (e.g. finishing college, going to grad school), and if so what?

No.

Where do you live now, and where would the company be based after YC?

SF. SF.

Are any of the founders covered by noncompetes or intellectual property agreements that overlap with your project? Will any be working as employees or consultants for anyone else?

We both have CIIAA's that could cover this work.

Dan's company is pretty far away.

Zac declared this idea when he signed his at Stripe. He's asked Stripe for an IP waiver letter, or whatever it's called.

(I also described this entire idea in a youtube video I sent to you in December before we didn't accept a late interview, so...there is a lot of documentary evidence that I had this IP before Stripe).

Was any of your code written by someone who is not one of your founders? If so, how can you safely use it? (Open source is ok of course.)

No.

If you had any other ideas you considered applying with, please list them. One may be something we've been waiting for. Often when we fund people it's to do something they list here and not in the main application.

Please tell us something surprising or amusing that one of you has discovered. (The answer need not be related to your project.)

"The failure, if it was one, lay in the fact that, having too much to hold on to, they slowly lost what they had. On the whole, it was those who had least who were able to move most freely to the new world which was coming into existence." --That reading The Making of the Middle Ages can make you think of everything from startups to the state of America in the world (this happened in December)

Dan and I had an unusual time applying to Y Combinator.

In September 2012 we started talking about the company that would become Standard Treasury. Primarily we were interested in why there wasn't an API platform that focused on ACH.[1] It's a core payment type and is pretty much a pain in everyone's behind. Things came to head at Thanksgiving time, when Dan and I had dinner at a restaurant in New York City and hashed out a vision we had for a "Twilio for financial services".

After that, though, I interviewed and got an offer from Stripe in the first week of December. Then began a little bit of a dance. John and Patrick Collison were very generous with me while I tried to decide whether to work at Stripe or start my company with Dan. Many long emails were exchanged and the Collisons showed a huge amount of patience as I decided what to do. In the midst of that — in early December, two months after the deadline — Dan and I applied to Y Combinator for the Winter 2013 batch.

But, we didn't hear anything back from YC.

Dan was still working on Giftly and I was really in love with the Stripe team and culture. After a couple amazing phone calls with Patrick, I decided that I should go work at Stripe, really get a feel for startup life, and learn all I could.

I moved to San Francisco and the Friday before I was to start at Stripe we got the following email from Harj:

"thanks for the yc app. do you think you'd be able to make it to PA on Monday [my first day at Stripe] for a late interview? it's the day before YC officially starts but we'd like to meet you in person."

I had literally spent days making this big decision to go work at Stripe, not do my own thing, move to San Francisco (which Stripe paid for) all to have YC want to interview me at the 11th hour! Shit.

We didn't take the interview. It just didn't feel quite right.

But that one little email from YC likely made it destined that I couldn't stay at Stripe for long: that it likely wasn't going to work out for me there. That tiny bit of validation — which really isn't much validation at all when you think about it, they interview a lot of people — propelled Dan and me think about the idea more, to talk about the idea more, and to mention it to friends. Eventually I was bringing it up at Stripe and had a conversation with the General Counsel about how to handle my IP questions.[2] Dan and I would be emailing people at Wells Fargo from our personal computers at night trying to figure out what was possible for our business, while I would be talking to other people at Wells Fargo during the day. We couldn't talk to venture capitalists, but we were socializing the idea with people, some of whom were even investors in Stripe.

That wasn't sustainable.

Stripe taught me a huge number of lessons about engineering culture, transparency, emailing writing, business development, and more. First and foremost though it partially demystified the startup world for me. I had worked in government before and held startups in awe. They are awe-inspiring. Building a company is so implausibly difficult. But in many ways when you're employee 37 at a startup, particularly one that is killing it, you think a lot about starting your own company. It only highlights the idea of being a founder. It only dares you to build a similarly great company.

So we applied to YC again. We got an interview, again. Again, I wavered and wasn’t sure that I wanted to leave a rocket ship. Again, we turned down the interview.

Then it all came together at the same time.

Dan’s company, Giftly, was sold — he knew the deal was coming together. That happened on a Friday. On Monday, Patrick and I had a serious talk where it was decided that I’d likely be happier if I did my own thing. In fact, my one-foot-in, one-foot-out approach hadn’t done Stripe any favors or made me particularly popular within the company, and it turned out to be better for both me and them that I move on.

On Monday night we emailed YC to ask for that interview we were offered. We emailed alums we knew. Several of them told us to “just go down there and wait.” Thankfully we didn’t have to make that decision. On Tuesday morning Kirsty, YC's CFO, emailed us. If we could make it down to Mountain View in an hour then we could interview that morning.

We were very nervous and frantic. We rushed down, driving 85 on the 101. Dan and I are practicing our pitch back and forth. We’re coming up with questions to answer. We are incredibly nervous. We hit traffic — you always hit traffic on the 101 — and we freaked out. We weren’t really prepared at all.

We arrive at YC, check in, and although we’re a minute late, so are they. We sit down to wait. When you’re waiting to interview at YC they have some alumni there to chat with you. To calm you down. They told us we would have a minute or two to present our pitch and then we would get questions. Try to be succinct. You’ll do fine.

We walk in and we shake hands with the partners. We begin to sit down and before our butts even hit the chairs, Sam Altman shoots “Isn’t your business just Dwolla?”. The rest of the ten minutes went by as a blur. [3]

That night I got the phone call. We had gotten in to YC. They made us the offer and I accepted. The phone call finished with Geoff asking, “Can you make our introduction session tomorrow morning?” Another trip to be taken on the 101.

Footnotes

[1] We either weren't aware of or very impressed by some of the existing solutions. 

[2] One of Stripe's secret weapons is their General Counsel. He's a lawyer whose first instinct is "we'll find a way" not to say "no". [

3] During the drive from San Francisco to Mountain View, Dwolla had announced their Series-C led by Andreessen Horowitz