implement a customer identification program (CIP)

[chadwhitacre]

With the move to a lower-level processing infrastructure (#67, #3377), we need a customer identification program (CIP) as part of our AML program (gratipay/inside.gratipay.com#119). Beyond that, we'll need a customer due diligence (CDD) program: gratipay/inside.gratipay.com#219.

(Ftr, Transpay rejected us partially for not having this (#417 (comment)), and Stripe wanted this, too (#3245 (comment)).)

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

[Changaco]

Stripe doesn't want the identity of the sender in the way you're implying, it just wants to connect payouts to charges, because a credit card number is sufficient information for the authorities to identify the sender.

What we need is identity information for payins that use anonymous methods like Bitcoin.

What we probably don't need is the identity of users who merely transfer money they've received to another Gratipay account, they're just smokescreens and should be ignored.

[chadwhitacre]

+1 from Braintree at #3287 (comment).

[techtonik]

Ids and personal information makes Gratipay a likely object for cyber attacks. That needs a completely different level of security and effort. I'd really like this stuff to be provided as opt-in and outsourced validation service that really need it with explanation why we need it. Otherwise we are no different from all ubiquitous Spyware 2.0 around there.

[chadwhitacre]

Taking this off of Balanced Shutdown but leaving as three-star.

[chadwhitacre]

Back on Balanced Shutdown. I think we seriously risk Citizens (#3366) rejecting us if we don't have this, based on previous experience with Payoneer (#481) and Transpay (#417).

[chadwhitacre]

Ids and personal information makes Gratipay a likely object for cyber attacks. That needs a completely different level of security and effort.

Agreed. See gratipay/inside.gratipay.com#214.

I'd really like this stuff to be provided as opt-in and outsourced validation service that really need it with explanation why we need it.

We can't make it opt-in. We need to verify identity for, at a minimum, all of our customers (receivers), for these reasons. We were outsourcing this to Balanced, but the point of this ticket is that with our new processing infrastructure we are taking on ownership of our own compliance program. +1 for explaining why we need to collect and verify identity.

[chadwhitacre]

outsourced validation service

See #2449.

[chadwhitacre]

The FFIEC manual: Customer Identification Program (examination procedures).

Here's the USA PATRIOT Act (PDF). The identity verification requirements for financial institutions are in section 326 (p. 46).

[chadwhitacre]

"A risk-based approach means that countries, competent authorities, and banks identify, assess, and understand the money laundering and terrorist financing risk to which they are exposed, and take the appropriate mitigation measures in accordance with the level of risk."

http://www.fatf-gafi.org/documents/riskbasedapproach/risk-based-approach-banking-sector.html

[chadwhitacre]

§326 of the Patriot act amends 31 U.S.C. §5318.

[chadwhitacre]

Customer Information Required

The CIP must contain account-opening procedures detailing the identifying information that must be obtained from each customer.⁴⁵ At a minimum, the bank must obtain the following identifying information from each customer before opening the account:⁴⁶

• Name.
• Date of birth for individuals.
• Address.⁴⁷
• Identification number.⁴⁸

Based on its risk assessment, a bank may require identifying information in addition to the items above for certain customers or product lines.

---

⁴⁵ When an individual opens a new account for an entity that is not a legal person or for another individual who lacks legal capacity, the identifying information for the individual opening the account must be obtained. In contrast, when an account is opened by an agent on behalf of another person, the bank must obtain the identifying information of the person on whose behalf the account is being opened.

⁴⁶ For credit card customers, the bank may obtain identifying information from a third-party source before extending credit.

⁴⁷ For an individual: a residential or business street address, or if the individual does not have such an address, an Army Post Office (APO) or Fleet Post Office (FPO) box number, the residential or business street address of next of kin or of another contact individual, or a description of the customer's physical location. For a "person" other than an individual (such as a corporation, partnership, or trust): a principal place of business, local office, or other physical location.

⁴⁸ An identification number for a U.S. person is a taxpayer identification number (TIN) (or evidence of an application for one), and an identification number for a non-U.S. person is one or more of the following: a TIN; a passport number and country of issuance; an alien identification card number; or a number and country of issuance of any other unexpired government-issued document evidencing nationality or residence and bearing a photograph or similar safeguard. TIN is defined by section 6109 of the Internal Revenue Code of 1986 (26 USC 6109) and the IRS regulations implementing that section (e.g., Social Security number (SSN), individual taxpayer identification number (ITIN), or employer identification number).

http://www.ffiec.gov/bsa_aml_infobase/pages_manual/OLM_011.htm

[chadwhitacre]

At a minimum, the bank must retain the identifying information [...] obtained at account opening for a period of five years after the account is closed.

http://www.ffiec.gov/bsa_aml_infobase/pages_manual/OLM_011.htm

[chadwhitacre]

31 C.F.R. §1020.220: Customer identification programs for banks, savings associations, credit unions, and certain non-Federally regulated banks. (PDF)

[chadwhitacre]

Alright, I finished a pass through the CIP overview and procedures from the FFIEC examination manual. Let's think about how to adapt this to our situation ...

[chadwhitacre]

Here are the questions I see for us:

• What information should we collect?
• How should we verify information?
• What should we do if we are unable to verify information?
• How long should we retain information?

[chadwhitacre]

Here's the information I think we should collect:

• for individuals
  • name
  • date of birth
  • address
  • identification number
• for businesses
  • name
  • date of incorporation or organization
  • address
  • identification number

Collecting national identification numbers significantly increases our information security risk, as @techtonik points out. However, I don't see how we can properly deliver "payments and payroll for open work" without that information.

A Gratipay Team is a company, even if only a sole proprietorship equivalent. On the payroll side, our teams will need the id numbers of their members (i.e., contractors, employees, and owners) in order to fulfill their tax obligations. If Gratipay doesn't collect this information, then we're putting the burden on our teams to safely collect and store this information on their own. Accepting that burden ourselves provides immediate value to our team customers by relieving them of it, and to our team member customers by streamlining the process for them: once you're registered on Gratipay, you can work for any team on Gratipay without having to provide your identity information again. It also puts us in a position to provide significant additional value down the line to both our team and member customers by streamlining their tax reporting for them.

On the payments side of the equation, our teams want to accept payments from both individuals and corporations. In fact, I would say that corporate payments are key to the success of many of our (current and prospective) teams, because corporations control so much of the world's wealth. We've learned on #1199 that corporate supporters need invoices to support their accounting procedures, and the lack of invoices has hampered our uptake with corporations. Invoices require id numbers, so no id numbers means limited access to corporate wealth for Gratipay teams. That's strategically untenable for us. Moreover, the fact is that we're already handling ids: I double-checked, and for the first invoice we sent on #1199, we did collect a tax id number from the user in question.

@copiesofcopies introduced an idea to me on the phone a few weeks ago (by stating the opposite as an obvious fact): Gratipay wants to be ADP.

That needs a completely different level of security and effort.

Yes. Welcome to Gratipay 2.0.

As Paul Graham suggests, great companies solve difficult problems:

A company is defined by the schleps it will undertake. And schleps should be dealt with the same way you'd deal with a cold swimming pool: just jump in. Which is not to say you should seek out unpleasant work per se, but that you should never shrink from it if it's on the path to something great.

[...]

Why work on problems few care much about and no one will pay for, when you could fix one of the most important components of the world's infrastructure? Because schlep blindness prevented people from even considering the idea of fixing payments [before Stripe came along].

Probably no one who applied to Y Combinator to work on a recipe site began by asking "should we fix payments, or build a recipe site?" and chose the recipe site. Though the idea of fixing payments was right there in plain sight, they never saw it, because their unconscious mind shrank from the complications involved. You'd have to make deals with banks. How do you do that? Plus you're moving money, so you're going to have to deal with fraud, and people trying to break into your servers. Plus there are probably all sorts of regulations to comply with. It's a lot more intimidating to start a startup like this than a recipe site.

That scariness makes ambitious ideas doubly valuable. In addition to their intrinsic value, they're like undervalued stocks in the sense that there's less demand for them among founders. If you pick an ambitious idea, you'll have less competition, because everyone else will have been frightened off by the challenges involved.

Layering an economy of gratitude, generosity, and love on top of the global financial system is a monumental schlep. I say let's do it. 🙋 🏊

[chadwhitacre]

We have some of this information for some of our users already. It's stored in Balanced. Here are the APIs to get it out:

https://docs.balancedpayments.com/1.1/api/customers/#fetch-a-customer
https://docs.balancedpayments.com/1.1/api/customers/#list-all-customers

Can we get it in an export?

[chadwhitacre]

We should make it easier to update one's address than to update one's name, date of {birth,registration}, or national identification number.

[chadwhitacre]

We should take a preliminary pass through gratipay/inside.gratipay.com#214 first. It may very well make sense to look into storing this info in a separate database from the main one, to limit access.

[chadwhitacre]

Done with preliminary pass through gratipay/inside.gratipay.com#214. Segmenting the vault from our main database would reduce our scope for PCI DSS compliance, yes.

[chadwhitacre]

Here was Transpay's requirement/suggestion at #417 (comment) for what to collect:

Below $1000 (per transaction? per year? per giver-receiver pair?) we need the following for the sender:

• First Name
• Last Name
• Phone Number
• Email Address
• Home Address
• Country of Residence
• State/Province
• Zip Code
• City
• Date of birth
• Nationality
• Security question 1
• Security question 2

Above $1,000 we need state id/passport, and that's where Jumio (#2449) would come in.

[chadwhitacre]

Brainstorm: only use business IDs, no personal IDs. We're about work! Any team owner should definitely be using one, and any member of a team could/should also being using one, as a contractor. EU VATs as well as US EINs can be programmatically verified. Yeah this feels right.

[chadwhitacre]

Hmmm ... but then what about legal owners (as opposed to Gratipay owners)? Like, do I need to get an EIN for myself to be a member of the Gratipay team? EINs are free and cheap. Are VATs, generally? EIN/VATs also wouldn't work for true blue employees, but maybe that's okay, and Gratipay is for contractor relationships.