Users
The users resource is used to create personal, joint or business user accounts. A user resource stores and managers user's KYC and authentication information. No bank account level details are stored on the object.
The user creation process allows you to create a user and add KYC ("Know Your Customer"). The required KYC is based on the requirements listed in your spec sheet. Please see below for details on the user creation process.
If you haven't done so already, Subscribe to Webhooks to inform you when a user has been created, or permissions/statuses have changed.
This call allows you create a user with the required KYC, as listed in your spec sheet. Please note that because KYC is processed asynchronously, we recommend that you submit all KYC in the same call as you create the user.
If you need to supply multiple base documents (as is the case for business or joint accounts), please supply a unique email/phone combination. This is because the base document ID is a hash of the email/phone, so duplicates will overwrite the existing base document.
Upon submitting KYC, the user's permissions and sub-document statuses will change as documents get validated asynchronously.
If the user has
SEND-AND-RECEIVE permissions, all documents were processed successfully.If the user does not have
SEND-AND-RECEIVE permissions, all documents may not have processed successfully or the user may be a potential match in a sanctions list.To check for the former, look at the
status of each submitted document and re-submit relevant documents.For the latter, check the user's
watchlists flag to determine if the user was flagged as a possible match by Synapse's KYC verification system.If the flag's value is
SOFT_MATCH|PENDING_UPLOAD, you will need to upload a government ID (GOVT_ID) to allow either for our KYC verification system or for our compliance team to recheck the user.If the flag's value is
SOFT_MATCH you will need to wait for the results of a compliance check.We typically process and verify KYC within a couple of seconds. However, this can vary, depending on traffic, number and size of documents submitted. If all documentation was successfully processed we will give the user
SEND-AND-RECEIVE permissions (i.e. the ability to create nodes, and originate and receive transactions).Please note that in instances where a Physical Document requires manual verification, the document will stay in
SUBMITTED|REVIEWING for up-to 2 full business day. These instances can be reduced if the image is clear, with all corners visible in case of a document with legible text. In case of videos, by ensuring that the video is clear with ample light and audio is clear and without distortion or disturbance.Because we verify SSNs by making an immediate initial verification followed by a more in-depth verification with the IRS in up to 2 full business days. So there will be some instances where the SSN will return back as
SUBMITTED|VALID initially and later transition to SUBMITTED|INVALID.In instances where the SSN returns as
SUBMITTED|INVALID, the user will be able to either upload their valid SSN (upto two more times) or an SSN card for further review and approval.Although we might not require government ID for a specific product we recommend to always build the user interface. As stated above, should a user be flagged on one of our sanction lists we will require the submission of a government ID.
Providing an accurate IP address of the user helps us and platforms combat fraud, and creating transactions from to/from/within sanctioned countries. Occasionally, certain platforms will submit their own IP on the API call header, we recommend not do so for the above described reasons.
To avoid race conditions for subsequent patch calls to users, nodes, and subnets, please consider doing one of the following:
- adding a 4-5 second delay
- waiting for a webhook response
- adding all the document information into one patch or post call.
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).
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 (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 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 are verified by our computer vision modules and are also periodically reviewed by the Synapse compliance and/or audit team. The manual audit 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. Any document that does not have automated verification built will be marked as
SUBMITTED on our system instead of SUBMITTED|VALID or SUBMITTED|INVALID. Go to Possible Sub-Document Status Values to learn more.We will close duplicate user accounts within the platform’s environment, as this practice helps mitigate widespread fraud.
We perform basic duplicate user checks based on user data that generally should be able to uniquely identify users within the same CIP tag. These checks include:
- 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)
We return a weighted numerical score indicating our relative confidence in the captured KYC. For more information please refer to the ID Score page.
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.
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.In addition to automated processes for closing accounts due to duplicate accounts and sanctions checks, we also have an enhanced due diligence (EDD) processes for flagging high-risk users for analysis, review, and closure.
A user subject to EDD review will be flagged (
flag:FLAGGED) with a user flag code (flag_code) to indicate the reason the user was flagged (see Possible Flag Codes to learn more). Along with this, if any additional documents are needed, you will see those show up under documents.required_edd_docs. The user will be expected to upload these documents to be able to unflag their account.Please note, when a user is flagged for EDD, an
account_closure_date is set as well. If an end-user fails to provide adequate documentation by that date, the account will be closed automatically. More details are provided under Possible Flag Codes.
The collection of KYC documentation from end users is an important step in the on-boarding process. This not only helps facilitate compliance with the Bank Secrecy Act, but also helps prevent account takeovers and fraudulent user activity. The identifying documents collected for both platforms and individuals helps us understand who our customers are, the nature of their relationship with us, and their expected activity. Different products and limits will have different KYC requirements because the underlying risks can vary greatly. We encourage platforms to collect more KYC than our minimum requirements.
This page (and its related sub-pages) are not intended to outline a Customer Identification Program (CIP), or set forth minimal KYC requirements (which will be detailed in your spec sheet), but rather to explain what we do with the information we collect.
Please note, although we continually strive to prevent fraud at any level, we do not and cannot guarantee a fraud-free product. We actively encourage our platforms to take the necessary steps to mitigate fraud, as the platforms will still be liable for user fraud and negative balances incurred as a result of fraudulent activity.
What KYC is required depends on which account types are being opened for your customers. We strive to keep the KYC burden as low as possible. Your KYC program is customized during the implementation process. If you are already a customer who wishes to further reduce the KYC requirements, please contact us.
While Synapse does monitor for unusual activity to assist our partner banks in their compliance with the Bank Secrecy Act reporting requirements, Synapse does not file SARs directly with FinCEN. Any platforms registered as MSBs, or otherwise required to file SARs (registered broker dealers) should remain vigilant in their reporting obligations. We do, however, encourage our platforms to report instances of fraud and or suspicious activity to Synapse for further review; our compliance team is equipped to perform further investigation.
We have the capability to on-board foreign users, if certain conditions are met. In these cases we will work with the platform to define KYC requirements that take into account the documentation those users have available but that also fulfill the security needs of KYC collection.
We block sanctioned countries automatically on our end both at the transaction level and the user address level. We continuously update this list. We recommend platforms also perform their own monitoring.
All users must accept Synapse's Privacy Policy which explains the data we collect and how we use such data. Synapse keeps aggregated and anonymized data for internal research and development, risk mitigation and machine learning purposes. Further information about how Synapse uses and stores its users’ data is available in Synapse’s Privacy Policy.
Last modified 1yr ago