escrow the minimum possible

[chadwhitacre]

Today's convo on https://github.com/gittip/www.gittip.com/issues/5#issuecomment-23756765, along with "what to do with interest" (#279) and "look into getting a banking license" (#938), make me think that maybe we don't want to escrow any money at all, if we can help it. @zeeg suggested this on Twitter a while back.

The problem with escrowing money is that then we should be doing something with it, namely, earning interest. That's a whole ball of wax in and of itself (#279), and basically turns us into a bank (#938). It's a lot cleaner, both conceptually and legally, if Gittip isn't a bank. (Gittip may still be a money transmitter, but that's different than a bank; see #938 for now, though.)

In order not to hold money in escrow, we would need to require a bank account (or other funding sink) to be attached before we could move money on any recipients behalf. If the deposit fails then we would need a retry-then-refund algorithm, and if that fails then ... eep (that's why I say "as little as possible.").

We need a real EU story (#126) before we can do this. Manual PayPal isn't going to cut it as a funding sink, and without a funding sink and without escrowing we will be seriously retrograde in terms of value for non-U.S. participants.

We need to change the payday algorithm to settle up each week, rather than holding over from week to week. @carsomyr worked out the basics of this on #449.

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

[mvdkleijn]

Not keeping money in escrow is (in my opinion) impossible. As soon as you keep money in escrow, it no longer matters how much you keep. So a couple of questions from my part:

1. Many organizations hold small and large amounts in escrow for clients. They surely don't all have a banking license? Do we really need one and if so, why?
2. Not keeping money in escrow is (near?) impossible for an organization like Gittip. Dealing with money is what we do, no matter if you like it or not. Just keeping it in escrow does not turn us into a bank. I still see no problem with my proposal at #5 that would allow the receiver to decide how to treat their money.

If that proposal was implemented, the only money Gittip would have in escrow would be that of people who chose to do so, that of inactive accounts, unclaimed accounts and interest earned on escrowed money.

1. Requiring a bank account to be attached by the receiver before people can donate to that receiver would seriously hamper Gittip's growth rate as it lowers Gittip's attraction. People just want to fund someone on Gittip and then shout "Hey, I got a present for you over at Gittip". (in my opinion)
2. Though it is very, very important, to get non-us payouts working, it will not solve the "escrow problem". True, we'd potentially have less money in escrow, but we'd still have it.

[chadwhitacre]

People just want to fund someone on Gittip and then shout "Hey, I got a present for you over at Gittip".

As it stands now, we don't move money in this case (see #28). Though you're right that requiring a bank account would throttle our growth even further.

[N]on-us payouts [...] will not solve the "escrow problem".

Sorry, didn't mean to suggest they would. I see it the other way around: we can't require a bank account without an EU bank account solution.

Not keeping money in escrow is (near?) impossible for an organization like Gittip.

Yup, hence "as little as possible," and not "none." As another example, I've already had a case where I've charged a company $5,000, which they're spending down over a period of many months. We have a ticket to offer pre-paid accounts generally (#113), and that would constitute an escrow.

[chadwhitacre]

The more we escrow, the higher the pressure on "what we're doing with it."

[mvdkleijn]

The more we escrow, the higher the pressure on "what we're doing with it."

Hmm... true, but my guess is the pressure is much higher if we forced escrow of money. If receivers can choose to receive lump sum payouts (i.e. one-time donations -> lump sum payouts) the pressure should(?) be lower.

Pre-paid accounts are essentially the same as one-time donations with spread payouts... when I look at the vehement opposition to forced spread payouts, I'd imagine we'd get the same reaction to pre-paid accounts. (never mind any escrow "problem")

[MikeFair]

People can not get their own money back out directly from Gt once they put it in and that's a major distinction from a bank. Gt is one-way handling agent following instructions it was given; and that makes all the difference in the world in being distinguished from a bank.

Escrow companies are also not banks and each state (in the us at least) has different laws regarding interest on money in escrow accounts (including places where anyone earning interest on those accounts is simply illegal). However Gt isn't an escrow company either. Someone can get their money back out (cancel the transfer) if the txn doesn't complete in an escrow account. A Gt gift isn't a txn and the money can only be redirected to someone else.

western union is not a bank; that's the best comparison entity to Gt at the moment.

As for the interest earned; if the interest earned is first applied to eliminate operational costs and then next applied to increase the amount of giving that's going on; people would be encoraged to, and feel like they are getting use/benefit from, front loading their accounts more.

Front loading, is a good and healthy practice for us and it should be encouraged.

Beyond being able to use the interest to eliminate costs/support the Gt community, the data regarding how much money has been committed to the network but not yet released; and where it's currently intending to go; is a powerful communication tool for how the community is allocating it's resources.

If someone is seriously thinking about relying on their incoming amounts as income (and let's assume we're talking real amounts, like at least a few hundred a month that could create a real problem for them if it suddenly vanished); then there's a difference between them seeing 1) "you're currently being gifted $250/week"; 2) "you're currently being gifted $200/week; and you're average weekly gifts for the last 12 weeks has been $200"; and 3) "you're currently being gifted $250/week; you're average weekly gifts for the last 12 weeks has been $200; and there is presently $5,000 in community accounts attributed for the upcoming gifts payments".

It's not gauranteeing delivery of those funds, it's simply stating that as long as nothing material changes then it's very predictable they will get at least the 5k over the next 26 weeks and very likely to continue getting somewhere between $200 and $250/week without anyone new adding in. That's a much more solid place to apply some rationality to relying on "gifts" as real income.

To make the rule explicitly clear on the interest though, I think the best rule, for the time being, would be that interest, if any is being collected/earned on money in transit through the network, shall be used in the interest of the Gt community decided at the sole discretion of the person/organization to whom the account where the money is being held belongs (aka whoever is on register at the bank as being the account holder).

atm there is only one account controlled by one entity (Zeta/Chad's account); there is a future though where there are many accounts controlled by many entities involved in the transfer of funds between people (think of them as middleman entities; and ultimately/ideally none of them are Gittip controlled accounts) - this distribution of accounts simultaneously distributes the risk of loss (both by reducing the total in any single account and by distributing the Fdic insurance coverages), the trust of good stewardship for these accounts, and the practice of being a distributed system simplifies eliminating bad actors if/when that should ever become necessary. The opportunity to control how the interest gets reinvested into the community is an incentive for becoming an account holder and the network/distributed nature of it is an incentive to remain in good standing with the community. If combined with a mechanism for people to choose which entity they want to host their in transit funds, then all the checks and balances bases are fairly well covered. However that's how I see it going, obviously not what we have today.

Today they can use any entity they want as long as it's Zeta. And that means Chad makes the call for now. ;)

Ok so what specifically to do with the interest: 1) Eliminate fees and overhead costs for critical infrastructure, staff, and services.

To be sustainable, the money to pay for things the community can not or does not provide for itself must come from the community members somehow.

Using the interest from in-transit money to eliminate all cost/overhead fees to people using the network is extremely healthy and a fairly equally applied benefit to everyone in the community.

Once the infrastructure costs of operating Gt have been eliminated; supporting the people at the core of making Gt run/making the community better is the next most critical aspect of improving our health so ensuring the critical community members are taken care of so they can focus on their community work is also a vital/equally beneficial use to the community (at the account holder's (Chad's) discretion - as the account holder, chad could designate someone else or some committee to make the call).

From there it gets a bit more vague but that's also where we're talking about tens of millions of USD in transit and that's a long ways off. However once we've gotten to that point and all the critical infrastucture/core people/services are well cared for, then I think the next best use for the interest is having it circle back into the Gt community as a gift.

What that means is the interest on the account(s) feeds back and adds itself to the whole of Gt giving. We can use several algorithms but the most straightforward of which is to evenly divide the amount of interest across all givers and prorata increase their gifts. They might even have some settings on their account that control how to distribute these funds.

Of course, once we've succeeded in creating the economy of plenty then we will most likely move off of interest bearing bank accounts and into something much more efficient. On Sep 5, 2013 5:48 AM, "Martijn" notifications@github.com wrote:

The more we escrow, the higher the pressure on "what we're doing with it."

Hmm... true, but my guess is the pressure is much higher if we _forced_escrow of money. If receivers can choose to receive lump sum payouts (i.e. one-time donations -> lump sum payouts) the pressure should(?) be lower.

Pre-paid accounts are essentially the same as one-time donations with spread payouts... when I look at the vehement opposition to forced spread payouts, I'd imagine we'd get the same reaction to pre-paid accounts. (never mind any escrow "problem")

— Reply to this email directly or view it on GitHubhttps://github.com/gittip/www.gittip.com/issues/1383#issuecomment-23864978 .

[mvdkleijn]

@MikeFair All good point and I agree completely. :+1: Apart from one thing: distributed accounts. I feel that's a very complicated, potentially inefficient setup and a completely new subject to discuss / work out. I'd not drag that into this already difficult topic. :smiley:

[chadwhitacre]

@MikeFair !!!! Welcome back! :D

I've cross-posted your comments re: interest over on #279.

[chadwhitacre]

We have the steady state algorithm in the repo now as of #1396.

[MikeFair]

@Martijn - thanks and I concur that discussing the details of distributed accounts doesn't go in this ticket.

The primary point for them here is resolving the matter of people disagreeing with the account holder's allocation of the interest.

Chad implicity identified that as one of the motivators behind wanting to minimize the interest (which is the topic of this ticket).

Assuming we're satisfied that encourafing lots of prefunding and lots of interest is healthy for the community and that won't cause us to become a bank; then what remains for this ticket? On Sep 6, 2013 4:49 AM, "Martijn" notifications@github.com wrote:

@MikeFair https://github.com/MikeFair All good point and I agree completely. [image: :+1:] Apart from one thing: distributed accounts. I feel that's a very complicated, potentially inefficient setup and a completely new subject to discuss / work out. I'd not drag that into this already difficult topic. [image: :smiley:]

— Reply to this email directly or view it on GitHubhttps://github.com/gittip/www.gittip.com/issues/1383#issuecomment-23934673 .

[zbynekwinkler]

What is the point of the steady state algorithm from #1396? What is it trying to do?

[chadwhitacre]

+1 from @nathany on Twitter.

[nathany]

The only way to entirely eliminate eschrow would be if everyone had a bank account setup and the funds were transferred directly. An option that has already been explored with Stripe Connect. Some things may have changed since then, but it still has some issues:

• gifts would no longer be anonymous
• many many more transactions make the transaction fees (particularly $0.30/per) unreasonable

More in line with this ticket is keeping the escrow, but reducing the amount put into escrow in the first place, see #1486.

[chadwhitacre]

Stripe Connect was a non-starter because it wasn't white-label (people needed to go sign up for a Stripe account before being able to use Gittip). The main point is correct, though: we could drastically reduce escrow by only moving money when there was a bank account on the receiving end. I mention that in the initial description on this ticket, though even there we will hit cases where a bank account deposit fails, and what do we do with the money then? Refund it to the credit card? What about when that fails? Retry the deposit? Or hold it until next week? It seems hard to completely eliminate escrow, in other words. And it would throttle our growth even further if we only moved money when there was a bank account attached. Not everyone minds escrowing their money in Gittip.

It should be noted that we do display whether a user has a bank account attached. For givers who are concerned about escrow, this information could be used to decide whether to give to someone.

[chadwhitacre]

@nathany Though I must say I'm impressed that you dug up https://github.com/gittip/www.gittip.com/issues/58#issuecomment-6366717. :-)

[chadwhitacre]

Closing in favor of #1486.

[chadwhitacre]

Reopening in light of repercussions of the Balanced shutdown. Storing value is running us afoul of Stripe (https://github.com/gratipay/gratipay.com/issues/3245#issuecomment-91112973) and probably MTL in general (#3321).

[chadwhitacre]

We have three four sources of escrow (IRC):

1. minimum charges, in order to support micropayments (if you give $1/wk we charge ~$10/9wk)
2. giving holdover (we hold funds for givers-who-receive week to week to cover next week's gifts, in order to avoid processing fees)
3. missing/broken withdrawal route (we allow receivers to pool their money in Gratipay)
4. payout minimums (we don't pay out until the user has accumulated a certain amount, for fee reasons)

[chadwhitacre]

Looks like we don't need to get this done before Balanced shuts down, but it's still something we want to keep open.

[chadwhitacre]

We can't entirely eliminate escrow, because of the asynchronous nature of some payment methods. ACH credits can fail and we don't find out for days. We have to keep track of the balance in order to deal properly with such failures.

[chadwhitacre]

Also, we probably can't get rid of the payout threshold as long as there are per-transaction fees associated with payouts.

[chadwhitacre]

Also, we probably can't get rid of the payout threshold as long as there are per-transaction fees associated with payouts.

And charging minimums in arrears doesn't entirely help: if I'm giving $1 each to 10 teams, then I'll be charged, but a given team will only end up with $1 in their account. Since PayPal doesn't have per-transaction fees, we could nip this source of escrow in the bud with a minimum payment of 50¢.

[rohitpaulk]

if I'm giving $1 each to 10 teams, then I'll be charged, but a given team will only end up with $1 in their account.

How is that a problem? They're only getting $1 because I only intended to pay them $1.

[chadwhitacre]

@rohitpaulk Our current minimum payout is $10, so the team owner will end up with $1 in escrow with us. Payout minimums are a fourth source of escrow.

[rohitpaulk]

Ah. I thought we were talking about the source that comes with payin minimums. :)

[chadwhitacre]

:)

[chadwhitacre]

We can refund the escrow due solely to payin minimums separately from the escrow due to other sources, and that wouldn't require user coordination. We need users to apply in order for us to pay out escrow, but not to refund escrow paid in that hasn't yet been shuffled around inside Gratipay.

[chadwhitacre]

And once we refactor payin minimums, we'll be able to drop payout minimums as well.

[chadwhitacre]

Sources of Escrow

Source	Turned off?	Flushed?
pooling	yes	no
holdovers	yes	yes (right?)
payin minimum	no	no
payout minimum	no	no
async payouts	n/a	n/a

[chadwhitacre]

I'm revising "Shuffle Escrow" as part of responding to https://github.com/gratipay/gratipay.com/issues/726#issuecomment-127693234. In so doing, it occurs to me that with a much lower escrow, we will have to take care that we don't "bottom out" our escrow account at PayPal. With a higher escrow, we always had enough to top up PayPal a week ahead of time, so that we could pay out immediately every Thursday. After we refund 1.0 balances (#3539), it seems likely to be the case that we won't have enough cash in escrow to float the weekly transfer to PayPal. What's the answer? I suppose we might build up and maintain a buffer from operations. That would need to be about $10,000 based on current usage.

[chadwhitacre]

Since the buffer required will grow linearly with the weekly volume we're processing, it'll be impractical to maintain such a float. If we're moving $1,000,000 a week, we'll need a $1,000,000 buffer! No: we should delay payout to reflect the real cash we have in hand. We need to offset payouts by a week.

[chadwhitacre]

As I think about corporate givers, I'm not sure that won't be another source of escrow: experience indicates that companies want to pay a big chunk once, and not be bothered with lots of little (expensive) transactions. That means either supporting one-time payments (#5) or escrowing the money for them while we dole it out.

Under another corporate use-case, I know @timothyfcook is interested in using Gratipay for payroll-only. He wants to fund a Team with money received separately, using Gratipay only for the sharing/distribution side. Surely for that situation there will also be an interest in adding money in larger chunks and letting it sit for some period of time.

[chadwhitacre]

Blog post about charging in arrears, ready for review: https://medium.com/gratipay-blog/charging-in-arrears-18cacf779bee.

cc: @mattbk @kzisme @rorepo et al.

[mattbk]

As I think about corporate givers, I'm not sure that won't be another source of escrow: experience indicates that companies want to pay a big chunk once, and not be bothered with lots of little (expensive) transactions. That means either supporting one-time payments (#5) or escrowing the money for them while we dole it out.

Is voluntary escrow a problem, legally?

[chadwhitacre]

Stripe mentioned "stored value" in the context of money transmission, but that now seems like a red herring. Nothing I've seen so far indicates to me that storing value is relevant to money transmission.

I just looked into the definition of a bank. It's not as clear as with money transmission (#3321). The place where money transmission is defined (cf. IG-192) defines a bank as:

Each agent, agency, branch or office within the United States of any person doing business in one or more of the capacities listed below:

(1) A commercial bank or trust company organized under the laws of any State or of the United States;

(2) A private bank;

(3) A savings and loan association or a building and loan association organized under the laws of any State or of the United States;

(4) An insured institution as defined in section 401 of the National Housing Act;

(5) A savings bank, industrial bank or other thrift institution;

(6) A credit union organized under the law of any State or of the United States;

(7) Any other organization (except a money services business) chartered under the banking laws of any state and subject to the supervision of the bank supervisory authorities of a State;

(8) A bank organized under foreign law;

(9) Any national banking association or corporation acting under the provisions of section 25(a) of the Act of Dec. 23, 1913, as added by the Act of Dec. 24, 1919, ch. 18, 41 Stat. 378, as amended (12 U.S.C. 611-32).

It seems to focus on how the entity was chartered rather than on what the entity does. I don't find anything about operating an "unlicensed bank" that's similar to what we found with operating an "unlicensed money transmission business." I guess this is how PayPal gets away with pretending they're not a bank:

The biggest criticism of PayPal is that it acts like a bank, but it isn't regulated like one. This means that PayPal offers none of the protection that real banks offer, and it isn't required to maintain any of the security, customer service or dispute resolution services that banks provide. At the same time, PayPal holds large amounts of their customers' money, makes millions of financial transactions and even offers credit and debit cards.

So why isn't it considered a bank? In 2002, the Federal Deposit Insurance Corporation (FDIC) declared that because PayPal didn't meet the federal definition of an entity accepting deposits as a bank, hold any physical money or have a bank charter, it was not a bank [source: Wolverton]. In other words, PayPal isn't a bank because it doesn't call itself a bank. As a result, most states license PayPal as a "money service."

Is voluntary escrow a problem, legally?

The answer seems to be, "No."

[chadwhitacre]

Reviewing https://github.com/gratipay/gratipay.com/issues/1383#issuecomment-93550690 ...

• [x] minimum charges—done in #3675. !m @rorepo
• [x] giving holdover—done in #3629. !m @rorepo
• [ ] missing/broken withdrawal route
• [x] payout minimum—nothing more to be done about this

[chadwhitacre]

Looks like #3754 is the last thing need to close this ticket, eh?

[chadwhitacre]

In order to land #3754, we need to finish cleaning up the exchanges table:

• avoid null route, ref, and status in new exchanges (https://github.com/gratipay/gratipay.com/issues/3822)
• finish backfilling route, ref, and status in old exchanges (https://github.com/gratipay/gratipay.com/issues/2779)
• constrain route, ref, and status to non-null (https://github.com/gratipay/gratipay.com/issues/3839)

[chadwhitacre]

Got this far enough for the Balanced Shutdown, taking off that milestone now.

[chadwhitacre]

It turns out that this isn't really necessary, and is in fact not workable in the long run. Online wallets are not banks (though there are some early rumblings that regulation may eventually be coming to stored value accounts). Storing value did not turn out to be the "crux" of the money transmission issue with Gittipay 1.0 as Stripe had suggested.

Moreover, in order to keep payments snappy, we actually need an escrow. It takes us days to move funds under the hood, but we want to be able to pay out on demand. We need an escrow to float the difference. This is normal operating practice (e.g., I heard through the grapevine that it's one reason Uber has had to raise so much cash—to float the payouts to drivers before payins from riders are fully in hand; e.g., Patreon doesn't payout by default, one has to explicitly set that up after the fact; e.g. PayPal QED).

[Changaco]

FTR escrow is exactly what you need a licence for in Europe, because holding people's money means that they may lose it if you do stupid things with it.

In fact a few months ago the financial watchdog in France came down on an almost-bank which wasn't properly managing their clients' money.

[chadwhitacre]

Good to know.