This repository has been archived by the owner. It is now read-only.

implement a customer identification program (CIP) #3289

Closed
chadwhitacre opened this Issue Mar 26, 2015 · 23 comments

Comments

Projects
None yet
3 participants
@chadwhitacre
Contributor

chadwhitacre commented Mar 26, 2015

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.

@chadwhitacre chadwhitacre added this to the Balanced shutdown milestone Mar 26, 2015

@chadwhitacre chadwhitacre added ★★★ and removed ★★☆ labels Mar 26, 2015

@Changaco

This comment has been minimized.

Show comment
Hide comment
@Changaco

Changaco Mar 26, 2015

Contributor

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.

Contributor

Changaco commented Mar 26, 2015

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 chadwhitacre changed the title from require identity from sender to collect identity ourselves Apr 10, 2015

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Apr 10, 2015

Contributor

+1 from Braintree at #3287 (comment).

Contributor

chadwhitacre commented Apr 10, 2015

+1 from Braintree at #3287 (comment).

@techtonik

This comment has been minimized.

Show comment
Hide comment
@techtonik

techtonik Apr 11, 2015

Contributor

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.

Contributor

techtonik commented Apr 11, 2015

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

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Apr 29, 2015

Contributor

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

Contributor

chadwhitacre commented Apr 29, 2015

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

@chadwhitacre chadwhitacre removed this from the Balanced shutdown milestone Apr 29, 2015

This was referenced May 25, 2015

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre May 30, 2015

Contributor

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).

Contributor

chadwhitacre commented May 30, 2015

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 chadwhitacre referenced this issue in gratipay/inside.gratipay.com May 30, 2015

Closed

Radar 8 #209

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre May 30, 2015

Contributor

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.

Contributor

chadwhitacre commented May 30, 2015

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 chadwhitacre changed the title from collect identity ourselves to implement a customer identification program (CIP) May 30, 2015

@chadwhitacre chadwhitacre referenced this issue in gratipay/inside.gratipay.com May 30, 2015

Closed

establish a customer due diligence (CDD) program #219

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre May 30, 2015

Contributor

outsourced validation service

See #2449.

Contributor

chadwhitacre commented May 30, 2015

outsourced validation service

See #2449.

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre May 30, 2015

Contributor

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).

Contributor

chadwhitacre commented May 30, 2015

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

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre May 30, 2015

Contributor

"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

Contributor

chadwhitacre commented May 30, 2015

"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

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre May 30, 2015

Contributor

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

Contributor

chadwhitacre commented May 30, 2015

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

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre May 30, 2015

Contributor

Customer Information Required

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

  • Name.
  • Date of birth for individuals.
  • Address.47
  • Identification number.48

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


45 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.

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

47 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.

48 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

Contributor

chadwhitacre commented May 30, 2015

Customer Information Required

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

  • Name.
  • Date of birth for individuals.
  • Address.47
  • Identification number.48

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


45 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.

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

47 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.

48 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

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre May 30, 2015

Contributor

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

Contributor

chadwhitacre commented May 30, 2015

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

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre May 30, 2015

Contributor

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 ...

Contributor

chadwhitacre commented May 30, 2015

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

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre May 30, 2015

Contributor

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?
Contributor

chadwhitacre commented May 30, 2015

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

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre May 30, 2015

Contributor

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. 🙋 🏊

Contributor

chadwhitacre commented May 30, 2015

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

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre May 31, 2015

Contributor

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?

Contributor

chadwhitacre commented May 31, 2015

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

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre May 31, 2015

Contributor

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

Contributor

chadwhitacre commented May 31, 2015

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

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre May 31, 2015

Contributor

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.

Contributor

chadwhitacre commented May 31, 2015

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

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Jun 1, 2015

Contributor

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.

Contributor

chadwhitacre commented Jun 1, 2015

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

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Jun 1, 2015

Contributor

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.

Contributor

chadwhitacre commented Jun 1, 2015

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

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Jun 2, 2015

Contributor

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.

Contributor

chadwhitacre commented Jun 2, 2015

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

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Jun 2, 2015

Contributor

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.

Contributor

chadwhitacre commented Jun 2, 2015

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.