SVB does a lot of venture debt. When venture debt is not repaid, SVB ends up owning the company, and can recover its exposure only if there is a buyer for the company or assets.
In early stage land where valuations are the result of a fairly small consensus, it is plausible that SVB would have over-extended.
These losses aren’t related to SVB’s debt portfolio. It’s due to their deposits being flighty.
SVB banks start-ups. Start-ups are spending cash faster than they’re getting it from VCs or customers. That leaves SVB with fewer deposits with which to fund their assets, so they must fire sell assets, which isn’t fun to do.
Doesn't SVB require a startup to keep a certain amount of cash reserves deposited in order to be eligible for things like merchant accounts and other "free" financial services?
Too much latency with official reporting to suss out an insured institution going over the cliff, indicator would be SVB reps meeting with FDIC examiners around receivership and liquidation. Doors close on Friday, receiving bank opens all the branches back up as them on Monday.
They used to be, after glass stegall in the 1930s.
this was a problem we learned during the 1920s
That has since been...... relaxed gradually, and almost completely done away with under Clinton in the 1990s. And then <10 years later we got the 2007/2008 crisis. But, the original separation of investment and banking didn't get re-instated during the dodd frank stuff that came after the last crisis.
Maybe, but that's not relevant here. All banks invest their deposits in similar types of debt. SVB just made some bad decisions in terms of timing and liquidity, and now they have to recapitalize. If they can pull it off successfully then the bank will be fine but shareholders will get diluted.
I used both Google's speech-to-text APIs and Assembly's APIs as well as some other ones to build Twilio Voice phone calling applications. The out of the box accuracy was way better with Assembly and its far easier to quickly customize the language model for higher accuracy in specific domains (for example programming language keywords). Generally I avoid using Google APIs whenever possible since they always seem overly complicated to get started with and have incomplete documentation even when I'm working in Python which should be one of the better supported languages.
Twilio Developer Evangelist here. Our Super SIM Product Manager @matjaxon had his comments held up since he has a new HN account so I'm passing this along from him: "You could send the same information to and from your devices using either SMS Commands or data but it would likely cost you a lot more to use SMS Commands. While our prices start at $0.10 per MB, we bill you in bytes.
For example, if each time your device checks in you exchange 50 KB of data, you could do that 20 times for $0.10. You can only communicate with your device twice using SMS Commands at $0.05 per SMS Command. SMS Commands are often used as a way of configuring some IoT hardware solutions where you can set configuration values over SMS or to communicate with your device if it seems like something is going wrong with its data connection. It's an extra way of interacting with your device that may be deployed into the field thousands of mile away from you."
The traffic bump and feedback was motivating and helpful to know I was on the right track with my content. I also learned there are some comments you just need to ignore and focus on your own vision :)
edit: my traffic was lower than I originally remembered, it was ~5k per month, not 25k in mid-2014
That's amazing. I would love to connect with you on Twitter if you would have the time. But since we are not following each other, I cannot send any messages. I am growing my blog similar to yours, but it is an personal blog though.
I wanted to keep this blog post as simple as possible so even beginner Python devs could get through it in one short sitting. However, it's definitely possible to integrate the command processing piece with backend APIs. I'd first try using the TextBlob library before an external service though: https://textblob.readthedocs.io/en/dev/
If you're in SF or traveling here sometime soon, you should definitely present this at the SlackDevs meetup where a bunch of us API users get together each month: http://www.meetup.com/SlackDevs/
There's nothing like big blocks of time to get some writing and coding done. Full Stack Python (https://www.fullstackpython.com) got some major updates with new pages, additional sections on current pages and new links to resources. The change log [1] and commit log [2] capture what's new.
Nice work by you and your team so far Leah! Quick question - what's the rationale behind having the two "Page TBD" top links in the nav? Is that to make sure the CSS/design works using placeholders or do you keep them knowing there are groups within the FEC that will definitely need 2 spots on the nav bar?
Thanks! It's a much simpler reason than that, I'm afraid. It's a reference to the fact that this isn't a comprehensive beta of the FEC site, but a beta of a few parts of the upcoming new FEC site. We're moving more beta functionality and content over in the future.
What do you see is being done to combat the issue of big contractors (Booz Allen, CGI, etc) who don't want the gov't building software with small teams because it would hurt their ability to obtain huge billion dollar contracts?
The existing contractors definitely don't like it, and on healthcare.gov, we learned to expect zero cooperation (indeed, plenty of interference) from the management of those companies. [1]
But ultimately, the people making the contracting decisions are agencies like CMS, HHS, the VA, and DHS. And with USDS, the agencies now have solid third party to provide technical advice--for example, that a consumer login system shouldn't cost $80 million to develop.
That's why you see results like the one quoted in the article, where a $200m initial healthcare.gov system was replaced with a $4m one. And if you read between the lines, you'll notice that the major federal contractor for healthcare.gov decided not to bid this year:
http://www.wsj.com/articles/healthcare-gov-contractor-optum-...
Sometimes the good guys win.
[1] On the other hand, the engineers at those companies generally want to do the right thing, if they are empowered to.
Thanks, it's encouraging to hear that the contracting officers are now getting better advice from technical folks who understand the small teams approach.
To be fair, a lot of the contractors don't like to cooperate with even each other (a huge part of the cost overruns are related to this reality, same as with private sector probably, too). Historically, the government has basically done almost nothing to referee bad behavior between companies on a contract, but because so many contracts are basically winner-take-all style, much of the fighting would happen before the contract starts.
I like to think that if everyone of the contractors had their customers' interests as priority #1 that the current situation wouldn't be happening. This is why I have few hopes of much changing down the road without a massive reform. The most skilled, talented contractors tend to have trouble surviving the system despite the funding vehicles available.
Even the SETA system created to "police" contractors a bit in the government's best interest is fairly easily gamed by the reality that people form relationships and that people can easily switch companies.
