Zac Townsend

I've written in earlier blog posts about how I don't think that credit card processing is a particularly good business (Credit Card Processing is a Hard Business and Credit Card Processing as a Commodity Business).

The gist of my argument is that a company in the card processing business has to reach truly massive scale before starting to profit. That is very hard to do. Square, Braintree, Stripe, and WePay prove that one can build valuable businesses but they have all achieved massive scale. Braintree after all was purchased mostly for their consumer product and its network while Stripe is working hard to build out Stripe Checkout so it can store consumer card data and do the same.

I was chatting with Jareau Wade, one of the co-founders of Balanced Payments, to get some idea of comparables on the scale. He pointed out that Vantiv processed roughly $530B last year and currently has a market cap of $5.7B. Heartland Payments processed roughly $120B last year and currently has a $1.6B market cap. At the time of Braintree's acquisition it had a processing run rate of $12B a year and was worth $0.8B. PayPal did not perceive Braintree's value as coming from their processing business, no matter how fast it was growing.

My comments on card processing led me to a thought experiment: maybe a processor could give card processing away and make money some other, higher margin way.

No independent sales organizations (ISO) - such as Stripe or WePay - could make the marginal cost of a charge zero because a huge percentage of the fee they collect goes to the card networks and their member banks (often called, not quite accurately, the interchange fee). In fact, big businesses can often get a card processing fee structure of interchange + some margin (known as "interchange plus" pricing). Maybe these processing business could charge everyone that way and find some other way to make most of their money. They can't quite make it zero margin because the processor does take on some risk but they could run this part of their business at break even.

A business that comes immediately to mind that could do this is Sift Science. They could just give processing away on top of their already profitable product. Sift Science is proving that a ton of businesses will pay them for better credit card fraud protection. They've cracked that nut but their system get better and better as they see more transaction. More data improves their algorithms and their blacklists. One way they could see a lot more transactions is if they just gave the transactional service away for free.

I'm not actually advocating that Sift Science get in to the processing business. They're running a great business and likely don't need a different path to user acquisition. It would certainly burden them to become an ISO with someone like Wells Fargo or Paymenttech. I am using them as an example though of how one could build a business that gives processing away while helping build a profitable core business.

As a contrast take Square, for example. They keep releasing (not particularly successful) products to try to get at bigger margins: Cash, Wallet, Register etc. Rather than running a processing business and then trying to find one's high-margin product it would be better to figure out a high-margin product where dirt cheap processing would be a way to get a lot of people to use it.

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)

(This is the second of three posts I'm doing this week about applying to YC. Tuesday I wrote about our crazy story of getting in to YC and tomorrow I'll post our application. Early next week — after the application deadline — I'll tell the story of our YC experience from bringing on our amazing third co- founder up to demo day).

I have had a few friends of mine ask me whether they should apply to YC and what advice I can give on the application itself. This is in addition to the 5 people Dan has met with this week about applying to YC.

Let me caveat my thoughts. Getting in to YC is similar to getting in to college. You're never quite sure how (or why) it happened. They don't send you a memo telling you their criteria and most of what you learn about the process is already public.[1]

Should you apply to YC?

I get questions about whether it's worth the equity. Short answer—yes.

YC gives you incredible focus and discipline. You have 100 days until demo day so get moving.

YC is a community. Your class is supportive, helpful, and in the trenches with you. They will always lend an ear or a hand.

YC is a guild. The alumni are incredibly generous with their time. We've gotten specific product feedback, investment, advice, and introductions from the extended YC family.

YC is a guide. The YC partners are successful and helpful. They will kick your ass in every conversation you have with them, improving your business and your thinking.

YC is a mafia (cough) I mean, a union. If someone treats you poorly then PG will treat them poorly.

Do you have advice on my application?

Be yourself.

Be concise.

Be demonstrably committed.

Don't lie. Don't bullshit. Don't exaggerate. Avoid adjectives and pronouncements.

Prove that you and your co-founder likely won't get divorced. This is how most companies die early.

Not-for-profits

Having worked in the social and civic sectors, a ton of my non-profit friends have asked me about applying to YC. I have no special advice to them except that they have to have some plausible story of how the NFP will grow. Startups are growth. YC funds startups.

I'd also suggest reading Glen's thoughts.

[1] This is basically true of all the advice from and operations of YC on some level. Almost all of the knowledge — although very little of the pressure and urgency — are in PG's many essays.

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

This post was originally published on the Mayoral Performance Analytics Initiative blog of the Ash Center for Democratic Governance and Innovation on December 5, 2012, but the blog no longer exists. As I'm currently attending the Code for America 2013 Summit and it reminded me of the idea. I never did write the rest of the series and David Eaves wrote a great response to me.

Guest Post: Introducing the idea of an open-source suite for municipal governments

VOICES FROM THE FIELD: Zac Townsend We will occasionally feature guest posts from those working in local governments. This is the first by Zac Townsend, the Senior Technology Policy Advisor and Mayor's Office Fellow in Newark, New Jersey.

New technologies are transforming the way that municipal governments and citizens interact. Open data platforms are releasing increasing amounts of information to the public, allowing anyone to understand and interact with the inner workings of government. Washington, DC, San Fransisco, and New York have all seen civic “hackers” build software applications on top of open city data. In many other cities, citizens have new avenues to report information and to make service requests. The Office of New Urban Mechanics in Boston is allowing citizens to make service requests through their Citizens Connect smartphone and text message applications, while Code for America has supported many cities in building applications for citizens to more easily make service requests through web applications.

Yet, much of the promise of modern technology has not improved the capacities of governments to get things done, to provide better services, or to directly support the most vulnerable populations. Too often, technology is used an excuse for why a particularly policy idea or service plan is not possible.

Tony Blair, in a short piece on transforming government in the 21st century, notes that government effectiveness and implementation are at the heart of good governance. He continues that “only systemic change, as opposed to incremental reform, will allow government to keep pace in a rapidly changing world”.

A systemic change is possible in municipal technology. As Linux changed operating systems and Mozilla Firefox changed the web browser wars, an open-source software suite of municipal government software could change municipal technology and, more importantly, municipal services. Open-source software makes publicly and freely available all the source code, end-product design, and implementation details.

Over several blog posts, I will outline and argue for a joint project between cities, philanthropic foundations, and academics to build an open-source suite of software solutions tailored to small and medium size cities. This series will build on an earlier post at The Catalyst, while this post serves as an introduction to the idea and the suite. The suite would ultimately provide well-designed and well-executed versions of key municipal systems through an absolutely free set of software code for cities (and their vendors) to use, build on, and customize.

There are currently 163 small and medium sized cities. They have populations between one hundred thousand and one million people. Each of these cities have similar core backend information technology systems--either designed and built themselves or purchased from vendors. Although cities consider themselves unique with individual technology needs, the creation of one set of open-source systems would reduce the costs for all cities, make maintenance easier, and allow cities to leverage technology to improve city services.

I am calling this idea “CivicOpen”, and one could imagine it as a sort of Mozilla or Apache for civic technology. The goals are to radically reduce information technology costs, to transform public sector services through user- and citizen- centered design and technology, and to allow any city to easily use and implement one system or all the systems.

Reducing information technology costs.

Costs have exploded within state and local governments predicted to spend $60 billion dollars a year on IT by 2014. When cities realize they need new IT systems--sometimes because of a desire for new business processes but equally likely because no one has the requisite outdated skills to maintain the system--they are often so expensive that the project has to be abandoned or critical resources have to be shifted from direct services to citizens into IT backend systems. Big vendors charge individual cities tens, if not hundreds, of millions of dollars on overly-complex and overly-specified technology projects.

Overall, city governments tend to be bad purchasers of technology, often relying on vendors to tell them what they need, to train their staff, and to even to write requests for proposals. By creating a freely available core set of systems--that is well designed and well executed--every city will have the option to implement core systems more cheaply (even if they need a vendor to customize and implement the software) when the time comes.

Transforming public sector services through user- and citizen- centered design and technology. The last twenty years have seen staggering advances in technology, user interfaces, and user-centric design while municipal governments have been left behind. Cities have been saddled with outdated, bespoke, and inefficient software solutions. These older system are are used as an excuse to avoid positive change-- “we can’t do that because our systems won’t allow it”--so services cannot be improved because of an old system that implements an outdated process from many years ago, in an ugly and unconsidered way.

CivicOpen would be an opportunity to use modern technologies to improve service delivery through user- and citizen-centered design, service design, and ethnographic research on service needs and delivery.

Allowing any city to easily use and implement one system or all the CivicOpen systems. Cities tend to have technology systems that sit on two sides of a spectrum: either overly customized on one end or an off-the-shelf closed-source solution that is not customized at all. Either way, interoperability and information sharing can be very expensive or impossible for municipal governments, and cities can get locked in a custom built or a closed-source ecosystem where only the products of [insert vendor name] play well together.

With freely available source code, CivicOpen will allow cities to tailor the suite to their needs, either by using or not using all the core systems, adding their own software as needed, or customizing the available software as far as needed. The suite would also be built with well-exposed and well-documented application programming interfaces (APIs) that will allow developers to load and utilize components as needed.

Jump-starting civic innovation.

By making this large, targeted investment in civic technology, CivicOpen will create and foster a large systemic change with municipal governments. The suite would change the cost-structure of technology in government, would bring new service designs to cities, and would allow cities to come along at their own pace.

As a preview of the series, I propose that the CivicOpen suite be designed from the start with a citizen-centric view, have data analysis and visualization available, facilitate open data and transparency at its core, be place-based and geocoded, and have best practices built into it. With open source software, cities would be able to have a core set of technology available to them for free, while still having the option to implement customized versions at low-cost. By being open-source, OpenCivic would allow any city to share code openly with other cities, and allow for upgrades to be propagated, for free, to cities based on others' work. The project could be jointly conducted by a coalition of alpha cities, and a series of academic, for-profit, and community partners. This public-private partnership will build a working software suite that would help retire billions of dollars from the cost structure of local governments with the following components:

• Budgeting and Financial Planning
• Financial Management and Contracting
• Personnel and Payroll System
• Citizen Relationship Management--Service Requests and Fulfillment
• Licensing and Consumer Protection
• Work / Asset / Inventory Management
• Land Use, City Planning, and Mapping
• Grants Management

Over the coming weeks, I will write posts that more fully elaborate the problems I see in government IT, the advantages of open-source for government, the design principles for the suite, the component systems of the suite, and a possible organizational structure of the joint initiative.

Zac Townsend is the Senior Technology Policy Advisor and Mayor's Office Fellow in Newark, New Jersey.

Dan and I have an angel fund called Deciens Capital. It is very small, with just a few hundred thousand dollars to invest. We raised the fund from friends and family a little over a year ago with the explicit understanding that we would make investments part-time.

The idea of starting a fund was inspired by our interest in some of our friends' startups. We were already helping out informally — with general advice about their businesses and startup ideas. Some folks had also asked us for introductions to investors we knew. That's when we thought that maybe we should do some investing ourselves, in the companies we liked and in those run by friends of ours.

While Dan and I were mulling that over, we came to realize that all of the businesses we liked were businesses that had some strong offline component or connection. They were marketplaces or in financial technology, education, government, eldercare, etc. They shared the core idea of improving the efficiency of some "real-world" process. Software eating the world indeed.

But that cliché doesn't do the future justice. In a comment on HN, PG noted that the massive fortunes of the future will be made by "startups in industries that didn't previously have them." That encapsulates the idea much better: that's agriculture (Sourcery), payments (WePay, Stripe, Balanced, Square), lending (LendUp, Lending Club, Capital Access Network), startup investing (Anglelist, WeFunder), insurance (Oscar), laundry (Prim), house cleaning (Exec, Homejoy), accounting (Indinero), etc. And let’s not forget banking (Standard Treasury). Many if not most industries can be improved with an injection of technology and the introduction of the startup ethos (disruption, growth, efficiency, data, etc.).[1][2]

In part, of course, we invest in these companies because we think there are fortunes to be made in them. Most of the economy is still untouched by the methods used by Silicon Valley's engineering-first companies. One advantage here, though, over some online-only businesses — such as social networks, photo sharing apps, etc. — is that you know the markets exist. Health insurance is out there waiting to be disrupted. But it's a schlep. Those businesses which figure out how to bring technological innovation to existing industries seem to be closer to having known, demonstrable value. Part of what I mean is that their having positive outcomes seems more likely/predictable. So, they seem like a better bet. But their value can also be more defined. It is more concrete because the need is evident.

This leads to the second reason we invest through this lens — we don't know if we have any comparable advantage in understanding technological innovations that are internet-only. In the winter 2013 YC batch there were approximately five big data companies. We have no idea which one is better. Put another way, we sometimes feel too stupid or too ignorant to judge whether this responsive-first web design tool is better than that other responsive-first web design tool, or this big spreadsheet is better than that big SQL table manipulator. We just don't know which one will get more traction. That's our own limitation. But when it comes to complex real-world systems and figuring out who has the best plan to jigger innovation into them... well, there we can shine. We have done it in the past and are trying to do it now. That's something we understand. We grok it. We're good at it, too.

Dan and I have invested in eight companies so far: Fuze Network,Tendertree, SponsorHub, [Keychain Logistics] (https://www.keychainlogistics.com), True Link Financial, wevorce, 7 Cups of Tea, and Simple Legal. In the near future, I'm going to write a blog post on each company and why we invested in them. The list is pretty clear to us though: credit card for the elderly, pushing money on to your credit card, eldercare, truck shipping, divorce, emotional support, and legal billing. I can even use those very short phrases to describe those businesses to the technophobic. Dan and I like being able to do that, and we hope to keep finding great companies like these.

[1] I adopted this paragraph from a comment I made on HN, which inspired this post. [2] This list of industries (and the companies listed in each industry) is non-exhaustive.

The Financial Times published a letter of mine:

From Mr Zachary Townsend.

Sir, Banks are “Realising the promise of new technologies” (The Connected Business, FT.com, September 30), despite being saddled by outdated and outmoded core banking technologies. Some of the best but least studied innovation is happening inside treasury management and commercial banking groups. There, far from the public eye, new technologies – such as application programming interfaces – are allowing financial institutions and businesses of all sizes to interact in new, faster ways. These technologies speed the flow of transactions for the business while decreasing risk and delivery costs for the bank.

Unfortunately, Eric Openshaw and Larry Albin continue the false dichotomy between the business and technology functions of banks. Ultimately, banks are “big” data and technology companies. At the centre of every bank is simply a data store that records who has how much money and the rules governing transaction processing. We call this data store a core banking system, which is then surrounded by delivery channels, risk management and other technologies. Banks, their boards and their shareholders will come to realise that huge portions of bank budgets and headcounts can be replaced by modern web technology if architectured correctly. Those financial institutions that remake themselves fastest in the model of software engineering first companies such as Google or Facebook, including picking a forward-thinking technologist as chief executive, will be the true benefactors of this new era in finance.

Zachary Townsend, Co-founder, Standard Treasury, San Francisco, CA, US

I wanted to expand on my post from yesterday after some great feedback. When I said that credit card processing is a commodity business, I was not saying that it was a bad business. It is just a hard market to be in exactly because processors need to get to a huge processing volume to generate meaningful revenue. In the credit card processing business, volume is the only metric that matters.

Companies that operate well in credit card processing are to be praised and any industry that is producing multiple companies with multi-hundred-million-dollar valuations is a very healthy one.

Having said that, many companies create something that is heavily differentiated from their competitors and are able to charge for that differentiation. Apple creates laptops that are 10x better than PCs running Windows, so many folks are willing to pay 2-3x as much for their laptops. Apple is able to take their differentiation and convert that into increased revenue and better margins.

In the world of credit card processing one cannot charge more if one says they are in the card processing business. Even if someone created an idealized solution for dealing with the payments system, once a user reaches sufficient scale they will be more concerned with the variable components of the processor’s cost than the lower fixed costs of development and set up.

That makes perfect sense. Most business wants to commoditize all of their inputs and differentiate their outputs. Technology businesses, and big businesses that rely on contractors or system integrators, will eat a month’s worth of horrifically painful engineering as it is much cheaper over the long-term than paying even an extra few basis points (hundredths of a percentage point) on each transaction. That is, if a business is doing enough processing that even small increases in marginal cost matter then increased upfront fixed costs won’t.

To succeed in credit card processing, a processor can succeed in one of two ways.[1]

The first is to clearly be in the credit card processing market, have razor thin margins, drives toward massive volume, and create a much better product so folks use the product at all. Businesses will not pay the processor more for a better product though. The processor will invest more and more money in their product but with margins that get more and more squeezed on the one hand by knowledgeable large enterprises, the processor’s most valuable customers, that want things like an interchange plus basis points pricing. And, on the other hand, processors will get squeezed by the absolute fixed costs of what the banks and card networks charge the processor. Adding insult to injury, as the processor gets better known fraudsters pay more attention to it, increasing the cost of simply operating

That is a hard place to be. That is the place that Braintree, Stripe, WePay, and Balanced operate in as well as a ton of companies that we are not as fortunate enough to have heard of. Ultimately, Square is there too — although their situation is slightly more complicated. It is not necessarily a bad business to be in: any entrepreneur would be happy to be added to the list of successful processing companies.

The other way to succeed in credit card processing is to figure out how to be a payments company without appearing to be one so you can just charge much more. That is what most marketplace companies succeed at doing. They have built a better and better product experience, whose heart is credit card processing, and they can charge for that something better. What they have done commoditize their input — credit card processing — and differentiated their output into “booking blackcars” or whatever it might be. Ultimately, their core business is having their customer pay with credit card and then paying it out to a wide set of merchants, e.g. drivers, via electronic checks (ACH). That’s Airbnb, Eventbrite and others. Whether or not those companies go on to use Braintree or Stripe as their payments gateway does not matter because they are making such a large percentage of every transaction.

Addendum: Braintree’s Revenue

Braintree is actually a gateway, rather than a full-stack processor, for many of their best known and largest customers. That is a high-margin game with little risk. In this world, they make $49/month and $.10/transaction from those customers. That might make their margins higher than I suggested yesterday. It is actually hard to calculate the precise difference or relative value of those different business models without knowing how much they would make on a percentage basis, the average ticket size for those customers, and how much risk the company’s processors take on.

If this is all mumbo jumbo to you, dear reader, then keep your eyes peeled for future posts explaining various parts of the payments system.

[1] This is a model for argument. I think it’s useful but I also know that I’m simplifying important and complex businesses into gross categories.

Thank you to Daniel Kimerling, Jim Brusster, Brent Goldman, and Spencer Sugarman for suggestions and edits.

Braintree sold to PayPal (Ebay) this morning, which reminded me that I am a payments skeptic and especially skeptical of credit card processing.

Credit card processing is a commodity business. Companies advertise fees like 2.9% but the vast majority of that goes to the card networks and to the issuing and acquiring banks. On top of that, the majority of processing does not actually happen anywhere near the posted rates. Most processing is by large merchants (following the ubiquitous 80-20 rule) and those merchants get volume pricing and other discounts.

The margins in the card processing business are incredibly small. A company would be very lucky to make .5%. That’s not discounting the money lost to risk or the cost of acquiring customers.

Let’s take the biggest online example. PayPal processed $144.973B last year. If that was entirely processed over credit cards than they would have made - assuming 0.5% - $0.724B on processing itself. $724 million isn’t all that much.

PayPal actually made more like $5.6B last year because they make most of their money by having people use electronic checks (ACH) while charging them credit card like fees, and by charging customers high, and opaque, foreign exchange and transfer fees.

Compared to the high margins of other software companies it isn’t all that great to be in the credit card processing business. One needs a lot of infrastructure to make not all that much money, and ultimately the biggest player in online processing business gets most of their revenue from other parts of their business.

Braintree is processing $12B a year with few revenue streams outside processing. A generous reading of their net income would put them at $60M a year. I doubt they are actually near that number and, as mentioned in the press, I assume that their purchase price is so high because of a generous understanding of the value of the Venmo network.

A bunch of folks have asked me what the acquisition means for Stripe. Having worked at Stripe I think they are the best online processor on the market. They have the best solution and certainly the best team.

But is the acquisition good for Stripe? Yes and no. Yes because over the next few months Stripe is going to have an influx of great customers and their transactional volume.

The one caveat is that, inside payment circles, Braintree was known for bidding ridiculously low in bake-offs between them and other processors for hot companies like Github, Airbnb, etc. So low that they might be losing money on the deals just to secure them. Some of these customers might not move over to Stripe exactly because they’re being given an unreasonable deal, one that PayPal can sustain. Those companies have also already built their payments systems on top of the Braintree’s infrastructure.

On the other hand, this deal pegs Stripe's short-term market value. Stripe is growing faster than most YC companies but let’s assume, given their time in market, that they are processing single digit billions a year. If Braintree sold for $800M and is processing $12B than the deal depresses Stripe’s implied valuation. I don’t think that matters since they have plenty of cash but the sale highlights how hard it is to be in the processing business. And, Stripe is the best there ever has been in the business.

I actually think that there are two interesting places to play in the credit card processing system these days. One is to be what I call a vertically specific payments company. That’s Airbnb, Uber, and Eventbrite and a different blog post entirely. The other is if you can own more than one layer of the processing stack like Credorax does in Europe.