escrow the minimum possible

[chadwhitacre]

Today's convo on #5 (comment), 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 allow for one-off tips #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//issues/1383#issuecomment-23864978
.

[mvdkleijn]

@MikeFair All good point and I agree completely. 👍 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. 😃

[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: 👍] 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: 😃]

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

[zwn]

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 #58 (comment). :-)

[chadwhitacre]

Closing in favor of #1486.

[chadwhitacre]

Reopening in light of repercussions of the Balanced shutdown. Storing value is running us afoul of Stripe (#3245 (comment)) 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]

:)

[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 #726 (comment). 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 #1383 (comment) ...

• minimum charges—done in Charge in arrears #3675. !m @rorepo
• giving holdover—done in Stop holding balance to cover next week's payments #3629. !m @rorepo
• missing/broken withdrawal route
• 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 (avoid null route, ref, and status in new exchanges #3822)
• finish backfilling route, ref, and status in old exchanges (backfill the status, route, and ref columns of the exchanges table #2779)
• constrain route, ref, and status to non-null (constrain route, ref, and status to non-null #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.