Stripe - Financial Products | Software Engineers | New York, NY, USA | Full-time | ONSITE

Stripe is the best software platform for running an internet business. We handle billions of dollars every year for millions of businesses around the world. One third of Americans bought something on Stripe in the last year.

Looking for all our open positions in San Francisco, Seattle, Dublin, Singapore, and other locations? Head over to https://stripe.com/jobs.

My NYC-based team is looking for engineers to help us build new financial products for Stripe users. You’ll work on problems that run the gamut from frontend product development, to backend infrastructure, to ML engineering. As you work in each of those areas, you will collaborate with experts in design, infrastructure, and machine learning to build robust, polished products that power the businesses of Stripe users around the world.

Apply here: https://stripe.com/jobs/listing/full-stack-engineer-financia... …or email me directly at (my HN username)+hn@stripe.com

You're correct -- Stripe self-imposed the seven-day delay early in its development.

While we may have chosen the seven-day delay, there are still a number of real challenges in moving to a faster transfer schedule. For example, we need to make sure funds are received from our banking partners in time to transfer them to our users.

(I work at Stripe)

I don't see why Square can start the ball rolling the next day but you need anything near 7 days delay. I figured it was just a way to make more money.

Stripe is trialling faster transfer schedules for US-based users, meaning you'll get your money in two business days instead of waiting one week.

If you'd like to be part of the beta, you can visit https://manage.stripe.com/faster-us-transfers and if you're US-based, you'll automatically be registered to participate in the beta. We're incrementally adding users to the beta, so we'll let you know as soon as you've been added.

(I work at Stripe.)

I should have written a more clear question. I read the page, and I understand that now you're doing two-day instead of seven-day transfers.

What I'm wondering is, "how is this possible?" How is Stripe now moving the money faster than before? What change made this possible? Did the stewards of the ACH system make a change that allows this? Is Stripe advancing funds ahead of time based on some kind of credit? Was the seven-day policy basically arbitrary before, and so changing it to two-day basically involves changing an integer somewhere in the codebase and updating documentation? Or is it something else happening at a different layer? More generally, what are the pieces at play in transferring money that influence transfer time? And which of these pieces has Stripe interacted with in order to transfer funds faster?

This is how most businesses have been funded for the past 30+ years AFAIK. Merchant account transactions are batched and settled nightly, then ACH'd to the merchant the next day. You get the money 1-3 banking days after charging someone. Stripe was the exception to the norm, and now they're doing what everyone else does. Holding onto your money before transferring it to you is something other merchant account providers only do on a case-by-case basis for accounts they consider at high risk for fraud.

Wild ass guess here: keep funds at all the major banks and do intra-bank transfers which are instant. We've considered something similar. You need enough cash to keep a pool at every bank large enough to cover transfers and you need a big enough customer base that the net flow into or out of your account at a particular bank is small enough that you can rebalance periodically.

I got an email like 2 weeks ago saying I was auto-enrolled in the two day transfer. I guess I'm just special where I don't have to fill out beta signups?

Your point regarding lost meaning is quite salient. It can be useful and enlightening when a learner reports a measure feature importance (such as in random forest models, http://www.stat.berkeley.edu/~breiman/RandomForests/cc_home....).

When you say "hashing makes the programming a little easier," I think you hit the nail on the head. I'm not trying to improve classification accuracy -- my goal was just to make it as easy as possible to learn on arbitrary structured data.

>my goal was just to make it as easy as possible to learn on arbitrary structured data

I'd be very careful about throwing arbitrary data at your learner, at least if you don't understand your data well. Oftentimes the predictors and response are not properly separated in the same way they will be during real-world usage (for example, in time); this leads to target leaks, where your model is effectively cheating by using data it won't have in production.

Target leaks are obvious when the classifier performs suspiciously well on in-sample test data, but sometimes the repercussions are more subtle but still very damaging in a production environment.

Hm, couldn't a hybrid approach deal with this? Eg hash all the data except a few dimensions you think are vital, and add those to the resulting hashed array?

Or location-aware hashing?

The hashing is not for security though, so why not keep a store of your hash + key. Again, added overhead but you wouldn't have to hash twice and you could just use the mapping table for debugging, rather than in operational code at the expense of resources.

First, please don't use hashkernel in production. It's a toy designed to showcase how hash kernels can help us (easily) learn on structured data.

VW is faster, smarter, and more featureful. However, it doesn't know how to learn on structured data.

This is a great question. The "unprincipled" part comes in the application of hashkernel. For example, any integer-valued fields encountered in structured data are treated as categorical features (whereas floating-point numbers are treated as continuous features). Of course, it's possible that some of these integer-valued fields should be treated as continuous features. When using techniques in ways they were never intended to be used, like treating continuous features as categorical, many of the assumptions that make something "principled" no longer apply.

eh, it's just binning :)

Great point! VW was actually an inspiration for this blog post. I don't believe it handles structured data quite the same way as hashkernel, but it does a great job of accepting both categorical and continuous features. We use VW models to classify all sorts of badness on my team at Facebook (http://www.newscientist.com/article/dn21095-inside-facebooks...).