Standard Treasury YCombinator Application

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.

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.

SF. SF.

No. (Our code was not written by a non-founder)

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

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

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.

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.

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.

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.

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.

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.

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.

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.

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)

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.

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)