ERC: YES compliance token

tysonmalchow commented 6 years ago

ERC document is here.

tysonmalchow commented 6 years ago

general comments after finishing the first draft - i think it's perhaps too long and possibly should move the "related works" section outside of the erc to a separate page?

MikeD123 commented 6 years ago

Re: Tiers.

For AML/KYC tiers, I think that we should use the formal language ("CIP" aka Customer Identification Profile. That's the language used amongst the industry and industrial organizations)

Minimum requirements per FinCEN (validator would be held accountable to these basically)

CIP 1
- Name
- Date of birth 
- Address
- *SSN (USA)

*For Finra compliant entities Non-US will require [source]

Pro's

Regulatory language aids credibility.
Conforms with regulated entities that exist now, and likely reduce friction for understanding the initiative.

Cons

Isolates the usage potentially by non-customer facing offerings I think?

Re: Separate pages

Fair call, although I think that it could end up creating two separate discussion threads if people want to ask questions etc... This means the next bunch of people that go through it might not catch the whole discussion.

Thoughts on adding some additional references regarding use cases or extensibility?

Terminology/Dictionary

Regulators - By Country
Service/Industry - GICS standard for consistency?
Certifications - Financial Services
Permissions/Accreditations if applicable (E.g. US Accredited Investor).

This sort of comes back to whether or not usage stays strictly for verification/compliance.

Random thoughts

Wyre, Inc. is the parent company, but Wyre Securities Inc. holding the broker/dealer license.

Is it worth having another option that gives the ability to reference a parent entity? E.g. Trading crypto on Robinhood is done through a different entity than the one where you trade securities. Would it be valuable to have this as something people could look up? I'm not sure it is, and referencing the link to the official registration would usually give that information. That said, putting more is likely going to allow more service discovery for non-regulated entities if all the other subsidiary/product offering types are available on-chain.?

Considering the above, it gives the label of accredited investor and all that. But would it add value having something like

Permitted Activities
 - serviceName. // E.g. Internet Gambling
  - serviceConditions. // E.g. Australia Only

Possible that this could be a separate piece of software that essentially interprets all this information to ensure there's minimal chance of the developer servicing the wrong type of user?

Scenario: The verification that is issued to Tyson would be determined by where he signed and the information submitted.The result would be visible on-chain as to what he is permitted to do/not do. Tyson McTysonface (he's Australian) would be able to be serviced for gaming.

Making everything as idiot-proof as humanly possible so that any random person can just jump in and build something without needing to know whether or not they are servicing users they shouldn't be.

My Question

Do we include interpretation in this? Digitizing the information is helpful, spoon-feeding interpretation lowers the barriers to entry even more.

MikeD123 commented 6 years ago

There's no function for validatorEntity creation, which shouldn't be in the interface anyway, right? But fwiw, could possibly look at the schema from schema.org?

Example using schema.org for legislation description?


  {
    "@context": "http://schema.org/",
    "@type": "Legislation",
    "@id": "http://fincen.gov",
    "legislationIdentifier": "https://www.treasury.gov/about/role-of-treasury/orders-directives/Pages/to180-01.aspx",
    "name": "Registered Money Services Business"
    "description": "Under the authority of the BSA and regulations issued pursuant to that Act, FinCEN determines whether grounds exist to assess civil money penalties against MSBs. The Money Laundering Suppression Act of 1994 requires every MSB to be registered by an owner or controlling person of the MSB, and makes operating an unregistered MSB a Federal crime.",
    "legislationType": "Regulation",
    "legislationDate": "February 28, 2011",
    "legislationDateEntryIntoForce": "March 1, 2011",
    "legislationLegalForce": { "@id": "https://www.law.cornell.edu/uscode/text/18/1960" },
    "about" : [ 
      {
        "legislationIdentifier" : {
          "@id": "Registered Money Services Business",
          "@type": "text",
      },
      {
       "legislationLegalValue": {"@id": "https://www.fincen.gov/msb-registrant-search/#Wyre",
        "@type": "text",
        "identifier": "31000129775875"
      }
          "organizationDetail": {
        "@id": "Dealer in foreign exchange, Money transmitter",
        "@type": "text",
      }.
   ],
  }
</script>

I'm not sure about this stuff really, but keeping everyutthing as close to the most common langauges and API endpoints seems like the least friction.

tysonmalchow commented 6 years ago

use the formal language ("CIP"

yes, good call. i will update our Tier 1 to include this. (as our tier 1 implies a degree of verification CIP does not fit as a substitute, but rather just used to describe what is included)

Thoughts on adding some additional references regarding use cases or extensibility?

so long as we have captured the structure of our motivations for the attestations we find directly useful right now, i think extensions of the standard (read: new YES marks) can be easily amended as needed

might not catch the whole discussion

yeah, one place for now is probs best

This sort of comes back to whether or not usage stays strictly for verification/compliance.

for the time being i believe it's a safe assumption that this is strictly compliance attestations. structurally it could be for anything, but it's usefulness really only extends to the actually implemented validators, so generalizing for the sake of it feels premature

MikeD123 commented 6 years ago

Rad, that makes sense. I feel like I'm more inclined to omit the events from the documentation as a good check for who's following along.

re: Schema, as explained, that was for if we were too provide additional resources for simplifying it more and more but as discussed we figured that'd be service/product on top, and not baked in it's core etc... (for others reading).

It's looking pretty solid, and I'd say it's close for a first pass from other teams. Whenever you're down, lmk.

Here's how I'd imagine the feedback to start out...

Compliance teams for regulatory validation and/or feedback for improvements and any blindspots missed. Little bit of back and forth on this would be nice to really validate the practical application, and not just the woo woo + blockchain.
Community for comments - Likely have FAQ and then suggested references to any complimentary standards that could either tighten the scope of this, or contribute value to any other standards.
Technical implementation example feedback (gas optimizations, best practices, etc...)
- Audit and implementation for Wyre to upgrade. // Consensys? Trail Of Bits? Open Zeppelin. Can ping MakerDAO on this one if needed, they've been through this process a fair bit. Similarly 0x, Augur. Good soundboards if/when needed.
Depending on the sentiment either turns out to be completely useless or it results in a positive reception. In the case of the latter, then exploring some sort of tooling to assist in streamlining people to get involved. I dig the https://choosealicense.com/ vibe. This stuff needs a ton of education and it's really shitty content to read if you're not interested... Haha, so basically... Everyone?

Literally typing for the sake of typing now.

MikeD123 commented 6 years ago

Dictionary for references

First pass, nothing in stone but good to get the ideas flowing for other readers...

Countries - ISO. // 👍

TBD - Example of what I've compiled here in Google Sheets if interested.

Industry - GICS (Wikipedia guide)
License Type (USA / State / NMLS).
License specifications by product/service offering.

Nationwide Mortgage Licensing System (NMLS) is the most prominent for filing with regards to money related activities. Insurance / Securities / Derivatives are separate.

Format: License Number - License Name - Industry Type
Example: ALCC002789 - AL Consumer Credit License - Consumer Finance, Debt, Mortgage

Practical examples for ecosystem as it is today. Could follow the same format as NMLS?

200. _licenseNumber_ - FinCEN - Registered Money Services Business
201. _licenseNumber_ - FINRA - Registered broker-dealer
202. _licenseNumber_ - SEC- Registered Alternative Trading System
203. _licenseNumber_ - CFTC - Swap Execution Facility
204. _licenseNumber_ - CFTC - Derivatives Clearing Organization
205. _licenseNumber_ - CFTC - Introducing Broker
206. _licenseNumber_ - AFSL - Australian Financial Services License
207. _licenseNumber_ - AUSTRAC - Registered

The US is primarily (don't quote, but high level I'm almost certain) the only one with state by state regs in terms of the MSB (Thanks Obama! 👍😜👍). Most others are country wide. Standardizing around that could save headaches for people needing that level of granularity. Just a thought... 🤷‍♂️

Either way, probably too early too worry about these things if nobody is receptive to the broader proposal. Woot.

sendwyre / yes-compliance-token