Users
Last updated
Was this helpful?
Last updated
Was this helpful?
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.
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 and 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 .
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 validate addresses submitted both internally and externally through the use of external vendors to verify addresses. Addresses are a crucial part of our base documentation and fulfilling KYC/KYB requirements during onboarding. Furthermore, valid address inputs are important as they are used for things such as mailing account balances in case of account abandonment or termination.
Address Requirements:
Physical Addresses Only: We currently only accept current physical addresses. Examples of acceptable addresses include residential or business addresses. PO Box addresses are not accepted and will be automatically marked as invalid.
Address Validation Process:
Verification: Every submitted address undergoes a rigorous verification process for accuracy and completeness, using both internal checks and external verification through our vendor partners.
Invalid Address Handling: If a PO Box address is submitted, it will be flagged as invalid. The API response for such cases will include an error message in the id_score_meta response field: invalid_physical_address -- Cannot use PO Box for physical address field. Please provide a valid physical address. This message is found under the reason key. The same error message will appear under the address_input_error key in the ADDRESS meta object.
For international phone numbers to properly validate, the number must be of the form:
+[country code][national number]
The + sign is required.
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. For users submitting passports issued in the United States of America, verification of a Social Security Number is also required. This is regardless of the user's country of residence.
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.
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)
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.
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.
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.
For more details about this process, please refer to .
After creating a user successfully, to perform actions for that user.
Please refer to the page for more details.
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 to learn more.
Learn more about how to .
We return a weighted numerical score indicating our relative confidence in the captured KYC. For more information please refer to the .
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 .
For more details please go to .
In addition to automated processes for closing accounts due to and , 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 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 .
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 .
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 .