When it comes to on-boarding customers, there is a fine balance between maintaining compliance, reducing risk and simplifying the experience. That’s why designing a good KYC program is key for FinTech companies.
However, the more we’ve helped companies build out their KYC programs on top of Synapse, the more we’ve realized that there is no one size fits all. Each company has different needs & different use cases require different KYC experiences.
We want to account for all these KYC needs — making our software as flexible as possible — so that if a bank and developer agree on a KYC program, our software can be configured to identify & validate that program in a matter of seconds.
So today we are announcing just that: A completely overhauled KYC engine that can theoretically support around 3,000 different KYC combinations.
These changes do not break anyone’s current Synapse integration. Some API calls have been deprecated, but they have not been removed. We will continue to support those API endpoints as long as our developers need.Moving on, here is how our KYC protocol used to work:
Step 1: Supply basic information on a customer to validate SSN
Step 2: Add a customer’s driver’s license picture (for personal accounts) or EIN document (for business accounts)
Over time we’ve realized that this works well for personal accounts and sole-proprietors but not so well in cases of joint accounts or business accounts since you cannot supply documents associated with different stakeholders.
To top that off, you would get a response like this from us:
This response does a good job of disclosing the document status and permissions on users when Govt ID & SSN are submitted. But what if you are submitting additional KYC information? As soon as you upload more than one physical document, this structure is more ambiguous than helpful because developers cannot tell which documents were submitted, valid or missing.
To remedy this limitation, we’ve come up with the following solution:
Instead of submitting virtual documents & physical documents separately, you can now submit multiple KYC documents in one API call.
Couple of quick observations:
Basic user info (like name, email, DOB, address) are decoupled from the SSN number.You can submit multiple documents per account (since “documents” is an array).You can supply something called “social_docs” (what?!!).You can specify document_type so we know which physical document you are submitting.
Why decouple SSN number from basic user info?
This small tweak allows us to build a very customizable KYC platform for you. Now developers can mix and match what kinds of information they need to collect on the user.
Why make “documents” an array?
By allowing you to submit multiple KYC documents for a user, our KYC engine is more adaptable for platforms that wish to open joint accounts or business accounts with multiple stakeholders.
What is “social_docs”?
Many of you already use Facebook, LinkedIn or Twitter for user authentication. Social documents allow you to supply us with those authenticated social profiles as further verification.
After submitting documents with our new KYC structure, you get the following response:
This gives you the breakdown of all submitted document statuses, rather than a single document status, providing transparency for which ones are valid and which ones aren’t.
We also now verify emails and phone numbers, so you know whether the email or phone number provided actually belongs to the user submitting the information (look under social_docs for this).
Plus, we have added an entry called “permission_scope”, which helps you know our thought process in assigning send and receive permissions, along with the limits and frequency. As a reminder, these parameters are customizable on our Advanced and Premium Plans.
This means you can determine when customers get send or receive permissions, as well as what their transaction limit should be on a daily, weekly or monthly basis.
We have also added another field called “cip_tag”. Using this tag, gateways can now have multiple KYC paths with which they can validate a customer. For example, if you use Synapse to facilitate payments for big corporations and smaller offices, you can design a separate KYC program for each.
Along with these changes, some more features have been added as well:
Tier based KYC: Gateways can now build out tiers in their KYC program. For example, a savings application can authenticate users with Facebook, rather than SSN, if they are saving less than $100 a day and then tier it up with SSN and other verifications.
Support for more document types: Previously Synapse only accepted and validated SSN and Driver’s Licenses. Now gateways can submit a diverse range of documents. You can see a full list here.
Support for Social document: Along with virtual documents (SSN number) and physical documents (Govt. ID), we have added support for social documents as well. This means gateways can use Facebook, LinkedIn or Twitter for authentication as well.
All these updates make for a KYC engine that is light years ahead of what is available in the market today.
That’s it for now. Currently this system is live on our sandbox environment for development. In next coming weeks it will be pushed to production as well. All the updated API docs can be found right here.
If you have any questions regarding the implementation, please feel free to reach out on our discuss page or email us at hello@synapsefi.com.
