How We Validate KYC

Base docs and virtual documents are validated through public and private databases and other APIs that we have integrated with. Meanwhile, physical documents, such as government IDs, are validated through our proprietary software, which includes:

• Image rotation, cropping, and enhancement
• Facial detection
• OCR on certain text fields to be verified against base document values (such as name and DOB).

Address

We use a group of external vendors to verify addresses. Addresses are part of our base docs and we always require them so we can send account balances in case of abandonment or termination.

Social Security Numbers

Social Security Numbers (SSN) are initially verified with W-9 certification by the users and checked against additional databases to ensure they are not associated with a deceased individual. Furthermore, every 24 hours we will verify SSNs directly with the IRS. It is because of this lag that we might require further submission of a Social Security card up to 24 hours after initial KYC was submitted.

Employer Identification Number (EIN) & Tax Identification Number (TIN)

Employer Identification Numbers (EINs) and other tax IDs are validated against information provided to Synapse when available. We typically require an EIN letter issued by the IRS or similar document (e.g. 147c). The value on the physical EIN letter will be verified against the virtual tax ID value entered, and we will also perform checks to confirm the veracity of the document itself.

Physical Documents

Physical documents are periodically reviewed by the Synapse compliance and/or audit team. This may result from unusual or unexpected activity, or may be part of a regular sample audit to ensure that the documents provided to us fulfill the items listed in each platform’s spec sheet. The Synapse team may mark items “invalid” as appropriate should the document be determined to be insufficient. Please note that this may result in the user becoming unverified, it is important to ensure proper documents are provided to Synapse. These documents have a status of “SUBMITTED” on our system, except for Gov ID and EIN which will have a “SUBMITTED|VALID” or “SUBMITTED|INVALID” status.

What Happens When a User Is Flagged by Any of Our KYC Validation Procedures?

Should a user be flagged during the validation process, they will remain unverified in our system. Should they wish to resubmit documents to become verified they may do so, granted it is allowed in the platform’s user interface. Should a platform feel that we were not able to verify a valid and sufficient document we are happy to manually review the document to make a determination. Please find additional information regarding potential sanction flags below.

Enhanced Due Diligence

Should Synapse be alerted to red flags related to KYC documents on file for a user, we may request additional documents outside of the scope of the CIP detailed in each platform’s spec sheet. This will vary based on the red flag identified.

Please find examples below to help clarify why this might be necessary.

1. Should a transaction be initiated from a sanctioned or other high risk country, which is inconsistent with the address on file for the user, we may request proof of address.
2. Should we suspect an account takeover or stolen identity, we may request a selfie with government ID to confirm that the user valid.

Duplicate Users

We will close duplicate user accounts within the platform’s environment, as this practice helps mitigate widespread fraud. We provide two micro-services to verify if a user account is a duplicate.

1. Default

• We perform basic duplicate user checks based on user data that generally should be able to uniquely identify users within the same CIP tag.
  • Combination of Name + Date of Birth (DOB)
  • Combination of Name + Driver's License Number (DLN)
  • Combination of Name + Physical Address
  • Combination of Name + Email Address
  • Social Security Number (SSN)
• The new simplified duplicate user account logic will prioritize the latest user account (i.e. keep that user open while closing others), determined by taking the most recent date among the following:
  • the most recent user account creation date (i.e. date user joined the Platform)
  • the most recent node creation date (please note that nodes older than 92 days will be ignored)
  • the most recent transaction date (please note that transactions older than 92 days will be ignored)

2. Blocked Lists

• If the user has committed fraud inside another platform we will not verify his/her SSN. Blocked Lists are currently enabled for consumer-type users.

ID Score

We return a weighted numerical score indicating our relative confidence in the captured KYC. For more information please refer to the ID Score page.

Enhancements to our KYC Verification

We strive to always improve the quality of all our services. We are continuously launching enhancements for our KYC validation service and to our related micro-services. To keep track of these changes, then please look at our changelog.

Sanctions Lists Explained

Synapse will run all users through our sanctions screening lists to comply with the requirements set forth in the Bank Secrecy Act, aimed to avoid facilitating transactions on behalf of sanctioned individuals, sanctioned entities, and/or wanted criminals. We will asynchronously run the KYC of each user through sanctions lists as well as additional screenings (e.g. FBI most wanted databases).

Our screenings lists are continuously updated to reflect changes in real-time.

The first step of the screening process is automated, based on controls in our KYC verification system that automatically flag potential matches. These soft matches (watchlists : SOFT_MATCH) are manually reviewed by members of Synapse's compliance team who will assess the validity of the alert. Please note that upload of a government ID (GOVT_ID) may be required before a full compliance check can occur (watchlists : SOFT_MATCH|PENDING_UPLOAD). Our compliance team will then determine if the document that triggered a user's soft match is either a true sanctions list match (MATCH) or a false positive (FALSE_POSITVE). If the the compliance team determines that the flag was a false positive, the user will be given SEND-AND-RECEIVE permissions and should be able to transact.

We offer different watchlists groups to best fit a platform's use case. For more details, please refer to Sanctions Tiers and Watchlists Explained.