Standard Treasury
Summer 2013AcquiredBanking APIs; acquired by Silicon Valley Bank in August 2015
Pressure-test this opportunity
Explore the risks and possibilities with a prompt for ChatGPT, Claude, or your agent.
Banking APIs; acquired by Silicon Valley Bank in August 2015
Explore the risks and possibilities with a prompt for ChatGPT, Claude, or your agent.
Standard Treasury set out to replace bank integrations built from giant FTP files and hundreds-page specifications with a REST API. Founded in 2013 by Daniel Kimerling, Brent Goldman, and Zac Townsend, the company sold banks white-labeled developer platforms for account operations, money movement, foreign exchange, and event notifications.[1][2]
The need was real; the route to market was not. The founders concluded in 2014 that they should build a bank, failed to raise a Series A for that strategy in early 2015, and aligned with Silicon Valley Bank instead. On August 6, 2015, SVB acquired the team and assets on undisclosed terms.[3] The team continued API work inside SVB, but the packet does not prove survival of the separate brand, an independently sold product, or a particular body of source code.
Image 1 / 3
The founding problem came from Kimerling's prior company, Giftly. Connecting that product to banking infrastructure exposed an integration world organized around bulk FTP files and specifications that ran for hundreds of pages. Banks held the accounts and payment rails that software companies needed, but their interfaces were not designed for modern application development.[2]
Kimerling and Townsend had known one another for more than a decade. The banking API was their original Y Combinator application idea, although they briefly explored alternatives. Townsend had worked at Stripe and in Newark mayor Cory Booker's administration, giving him exposure to both payments and policy. Goldman joined as technical co-founder and CTO. The current YC profile lists Kimerling as CEO, Goldman as CTO, and Townsend as head of product.[1][2]
Before committing to the product, the founders interviewed hundreds of founders, CFOs, and finance executives about what businesses wanted from banks. Kimerling captured the demand with one question: "why can't banking be like Stripe or Braintree?"[2] The comparison was about interface quality, not becoming a card processor. Standard Treasury wanted to give banks a modern surface through which business customers could automate treasury and accounting work.
The company joined YC's Summer 2013 batch. Contemporary reporting named the legal entity Financial Tech Inc., doing business as Standard Treasury, and said the three founders started it in 2013.[4] A $2.7 million seed round announced in May 2014 included RRE Ventures, Index Ventures, Data Collective, SV Angel, Y Combinator, Jay Mandelbaum, and Paul Buchheit.[5] Owler independently records the round; Andreessen Horowitz's current investment list includes the company, but the packet does not identify its check or round.[6][7]
Only one verbatim founder quote appears in the packet. A second cannot be supplied responsibly.
The first product was a REST API between banks and business customers. Its announced capabilities included electronic checks, transfers between accounts at the same bank, opening and closing accounts, and foreign-exchange quotes and execution. Webhooks for transaction postings were on the early roadmap.[2]
The customer was the bank, not merely the developer using the interface. Standard Treasury built, hosted, maintained, and supported white-labeled or co-branded developer platforms. Banks could present a modern interface under their own identity while outsourcing part of the integration layer. The stated benefits were lower servicing cost, less customer churn, more transaction volume, and automation for treasury-management and accounting users.[1]
The strategy expanded beyond an adapter. In 2013, the founders discussed a fuller technology stack that could eventually include core banking and account-balance systems. By 2014, they had decided the strongest way to deliver the API vision was to build their own bank.[2][3]
That ambition changed both scope and capital requirements. An integration layer can partner with existing institutions. A bank needs a charter path, compliance program, geographic strategy, risk ownership, and much more capital. The packet does not identify the intended jurisdiction or regulatory plan. Nor does it document security controls, uptime, reconciliation accuracy, API volume, or production customer outcomes.
After the transaction, SVB said the team would continue developing API services and planned releases within months. Later evidence supports continuation of the work: beta signups in late 2015 and a 2016 industry report linking SVB's open-platform strategy to APIs and developer tools for virtual cards and payment products.[8][10] That does not prove which source code survived or that a product continued under the original name.
Standard Treasury sold to banks and served their business customers through those banks. In July 2013 it claimed a pilot with one of the five largest US banks plus work with regional and midsize institutions, but named none. No contract value, customer count, API volume, or public case study appears in the packet.[2]
This market offered enormous strategic value but slow distribution. Every bank relationship implicated authentication, permissions, money movement, reconciliation, security, compliance ownership, vendor review, and legacy integration. The startup could standardize a developer experience, but it still had to secure bank-by-bank acceptance.
The founders used Stripe and Braintree as interface benchmarks, while their longer ambition put them closer to core-banking vendors. The packet mentions FIS and later banking-as-a-service firms only indirectly and does not contain a formal competitive map. The sharper distinction was architectural: either sit between many banks and their customers, own a bank, or embed within one institution.
The multi-bank platform promised broader distribution but required many difficult enterprise integrations. The own-bank strategy promised control over the stack but introduced charter, capital, regulatory, and geographic risk. Alignment with SVB traded independence and multi-bank breadth for one institution's permission, customer base, and operating infrastructure.
The company had graduated from Commerce.Innovated, an accelerator run by SVB and MasterCard, before the transaction.[8] That relationship reduced search costs on both sides: SVB already knew the team, and the team knew a bank willing to invest in developer access.
The intended model was enterprise software and service for banks: build and operate white-labeled developer platforms, then help banks reduce servicing cost and churn while increasing transaction volume. The packet does not disclose pricing, recurring revenue, gross margin, implementation fees, contract duration, customer concentration, burn, runway, or headcount.[1][12]
The $2.7 million seed is the only quantified funding round. Early 2015 Series A fundraising failed when investors worried about regulatory and geographic risk in the own-bank plan. That is not evidence that the original API platform had no demand; it shows the chosen expansion strategy required a financing case investors would not accept.[3]
SVB did not disclose acquisition terms. Price, cash-versus-equity mix, asset list, cap table, investor return, and employee retention economics remain unknown.[8]
Kimerling's question, "why can't banking be like Stripe or Braintree?", correctly identified developer frustration.[2] Jarvis's 2024 retrospective reached a similar conclusion from inside the team: the market need was right, but the business model was wrong. He said the earlier vision closely resembled Griffin's later model of an API-first commercial bank for fintech companies.[11]
The structural mechanism was permission. A startup could design an elegant API, but banks controlled accounts, charters, compliance responsibilities, and production integration. Selling a common layer across banks preserved independence but multiplied enterprise adoption work. Owning a bank unified product control but changed the company into a regulated institution. Embedding inside SVB gave the team permission to build, at the cost of the independent platform.
In 2014, Standard Treasury decided to build its own bank. It could not raise a Series A for that plan in early 2015. Townsend attributed the failure mainly to investor concerns about regulatory and geographic risk. The company responded by choosing the next-best route: close alignment with one bank that could deliver impact faster.[3]
This was a strategy correction, not proof that the API work failed technically. The packet has no reliability results, security assessment, production-volume metrics, or customer rejection data. It does show that the capital market would not fund the company's chosen route to owning the full stack.
YC and SVB described the August 6, 2015 deal as an acquisition of the team and assets. They did not describe a share purchase or acquisition of Financial Tech Inc.'s corporate entity. Kimerling and Townsend became SVB directors, and the former team joined the bank's information-technology organization.[3][8]
The HN beta thread and 2016 payments report show continued API-banking work. The report claimed onboarding could take as little as two days, but did not isolate Standard Treasury's causal contribution.[9][10] Later biographies say Kimerling led API Banking and Open Platform at SVB, while Chris Dean later ran SVB's API-banking group before founding Treasury Prime.[12][13]
Jarvis's later work at Griffin shows that technical and conceptual lineage continued beyond the deal.[14] But people, ideas, code, contracts, and brands are different forms of continuity. The packet supports team continuity and API work at SVB. It does not support a precise code-reuse claim, a separate continuing product, or conclusions about later SVB products and the bank's 2023 fate.