figure out cash flow post-refunds

[chadwhitacre]

We're about to refund most of our escrow: see #1383, #3763, and #3539. Once we do that, we're going to hit a cash crunch because of the time it takes to move the money we receive from Braintree into PayPal for MassPay. Historically we've floated the cash, so that we charge alice and pay out bob on the same day. But especially if the 1.0 refund goes well, we will no longer have the cash to float. That's kind of a big deal. What should we do about it?

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[chadwhitacre]

Ping @mattbk @rohitpaulk @rorepo @webmaven @kzisme @kaguillera et al. We need some quick decisions on this one, I think.

[chadwhitacre]

Simply put, the flow of funds is this:

1. We pull funds in (charge cards) on Braintree.
2. Braintree pushes funds to New Alliance.
3. We pull funds from New Alliance into PayPal.
4. We push funds out (MassPay) from PayPal.

Braintree settles funds twice a day (7am and 5pm). AmEx takes 4-5 business days to clear to our New Alliance account, and the rest take 2-3 days. (This isn't publicly documented, btw. I had to call Braintree support.)

I put together a spreadsheet with historical data on days to move money. In practice, it takes an average of seven days for money to get from credit cards over to PayPal. The best-case scenario is two days. The worst-case scenario is 11 days.

[chadwhitacre]

Fundamentally, we have two options:

• Continue to float cash.
• Desynchronize payins and payouts.

[webmaven]

It looks like you don't have any option but to desynchronize. Am I missing something?

[chadwhitacre]

@webmaven Our experience suggests that we would need to desynchronize by two weeks to do so safely. We can desynchronize in one of two ways:

• Abrubtly. On October 15 (the payday following the 1.0 refund), we don't pay out. We also don't pay out the week following. We start paying out again on October 29, once the money we charged on October 15 has safely reached PayPal.
• Gradually. We could conceivably move charges forward by charging more frequently, while maintaining our payout schedule. To safely pay out on October 15, we would need to charge triple this week. If we are willing to accept some risk (and it's highly likely that our float won't be fully depleted by October 15), we could come up with a gentler schedule.

The abrupt strategy is jarring for receivers, while the gradual strategy is jarring for givers. Yes, either is a short-term inconvenience, but it'd be wonderful to avoid inconveniencing our users more than we already have. And either way the primary problem with desynchronizing is insurmountable: it's kind of ridiculous to delay payments by two full weeks. That's a bad user experience. :-(

Since desynchronizing is a bad user experience both short-term and long-term, I think floating is an option worth exploring.

The amount of cash we would need to float is our expected weekly demand. Historically this has fluctuated by (shooting from the hip) up to ~10x from week to week. However, the largest fluctuations were due to our practice of pooling funds: our largest payout weeks were when someone had pooled funds for a year or two and then cashed out. Once we get through the 1.0 refunds, we won't have that threat anymore, and we could run with reserves closer to 1x or 2x, rather than 10x. Our average MassPay since the Gratipocalypse is $2,514.13 (see the spreadsheet), but of course that includes 1.0 payouts. Our average payin per payday since switching to Braintree (shortly after the Gratipocalypse) is a better starting-point: $1,162.15, with a max of $1,559.84 and a standard deviation of only $225. Let's say we use an 18-week average + 3σ as a formula for a safe float: $1,836.05.

We would need to adjust our float in response to growth and contraction, of course. It would grow linearly with our weekly volume: if we were to be moving $100,000 per week with a 40% standard deviation, we would need a $220,000 float.

If our float is part of our operations budget, this represents a significant expense. We currently have $1,427.66 in our operations account: it would take just about all of our money to fund even the bare minimum float we can anticipate needing on October 15. We would need to invest a lot of our income into building our float, as usage grows.

[chadwhitacre]

Brainstorm:

• We could drop from a weekly schedule to a monthly schedule, with payouts offset by two weeks. Actually, that wouldn't really add much value over desynchronization with a weekly schedule.
• We could back off on minimizing escrow (escrow the minimum possible #1383), in order to lessen or remove the need to build a float out of operations.
• We could talk to Braintree and PayPal to see if there's any way to speed up money movement. No matter what, though, we're not going to be able to bring it down to synchronous levels.
• We could go Dwolla-only. Dwolla is realtime, but they're also U.S.-only.

[chadwhitacre]

Note that the float needs to sit in PayPal, which means a) we can't earn interest on it (anymore), and b) we're playing a risky game. :-(

We would need to maintain a separate float for each new payout route we add (e.g., Dwolla, #726).

[chadwhitacre]

If we float cash for our receivers, we would need a plan for when the float breaks. Assume that we're using a 6-week average and we have these weeks:

week	volume ($)
1	1,150.00
2	900.00
3	1,500.00
4	1,300.00
5	900.00
6	1,150.00

That gives:

μ	σ	μ+3σ
1,150.00	232.38	1,847.14

Now let's say someone starts giving $1,000 in week 7. Now we have:

μ	σ	μ+3σ
1,316.67	469.75	2,725.92

And we have two problems:

1. We have to pay out $2,150 when we only have $1,850 in PayPal.
2. We have to float an additional $850 (47%).

Problem (1) we would have to deal with by either a) delaying the $1,000 payout (but what about the impending second $1,000 payout?), or b) handling the $1,000 payout out of band (e.g., via PayPal Instant Transfer instead of MassPay).

Problem (2) we would have to be prepared for with a second-tier "float reserve," an amount we ensured we kept in operations (not in PayPal directly) so that we could quickly boost our float.

[chadwhitacre]

I'm interrupting other work to think about this, because either way we go—float or descynchronization—we don't have much time to prepare for October 15.

[chadwhitacre]

What does Patreon do?

We don’t charge your patrons until the 1st of every month. It usually takes a full 72 hours for all patrons to be charged.

https://patreon.zendesk.com/hc/en-us/articles/203913509-When-are-my-patrons-charged-

Your funds will be sent to you on the 5th of every month if you've selected to receive automatic payments.

https://patreon.zendesk.com/hc/en-us/articles/203913499-When-do-I-get-paid-

How Do I Sign Up For Automatic Payments?

All you have to do is click a check box!

https://patreon.zendesk.com/hc/en-us/articles/204606155-How-do-I-sign-up-for-automatic-payments-

Interesting. So it seems that they do allow pooling funds indefinitely, and that this is the default behavior. They also do have a slight desynchronization, though only 2-5 days, not two weeks. They also use Stripe for some percentage of payments, and Stripe floats for them (just as Balanced did for us).

[chadwhitacre]

It's really disheartening to think about floating our receivers entirely out of operations. That's a lot of money!

It's also disheartening to think about offsetting payouts by two weeks. That's just unprofessional.

Maybe we should reconsider #1383?

[chadwhitacre]

It's also disheartening to think about basing our business on gently hiding people's money from them. 😞

[rohitpaulk]

Maintaining a float is the only way that we can ensure a good user experience for both givers and receivers 😢

I think we'd be able to pull off the float in the short-term, but as @whit537 said - In the long term, we'd have to invest a sizable portion of our income to build and maintain the float.

[jiri-janousek]

In case there will be an offset between charging and payout, it would be great to have a dashboard similar to Patreon's one to provide teams with information about progress. For example:

1. We are charging your patrons. It can take up to X days. $100 pledged by 25 patrons, $50 processed so far by 20 patrons.
2. We are transferring money for payout. $100 pledged by 25 patrons, $80 processed by 23 patrons. (2 declined)
3. We have sent you $90 ($10 fee). It can take up to X days. $100 pledged by 25 patrons, $80 processed by 23 patrons.

[chadwhitacre]

In the long term, we'd have to invest a sizable portion of our income to build and maintain the float.

And/or escrow user's money in one way or another, and use that to float payouts.

[chadwhitacre]

@fenryxo I've copied your comments over to #3612, since history pages are the closest thing we've had to what you're describing, and we need to bring them back for Teams.

[chadwhitacre]

It's unlikely enough that we'll actually be able to refund all of the money currently in our escrow that I don't anticipate a cashflow problem on October 15. There, let's take it that we're going to keep floating our receivers at least through the next couple weeks of refunds and the end of Balanced, and revisit this ticket once we're through those events.

[mattbk]

I think this is the best option:

We could back off on minimizing escrow (#1383), in order to lessen or remove the need to build a float out of operations.

[chadwhitacre]

Cash-flow has not been an issue post-refunds, because we failed to refund any significant portion of our escrow. We will need to keep an eye on our escrow when we grow again, but for now we're in okay shape.