KYC - SSN Prefill

We’re happy to announce we’ve rolled out Social Security Number (SSN) Prefill to production. FinTechs can now streamline their customer onboarding and personal identifying information (PII) collection process by removing the need to collect the full 9-digit SSN from a user.

How it works

FinTechs collect the last 4 digits of a user’s SSN (along with the name, date of birth, and/or address) and use that information to find the first 5 digits of the user’s SSN. This will allow a FinTech to stitch together the complete 9 digits of a user’s SSN, and in turn, use that information to perform full Know-Your-Customer (KYC) compliance on a customer while also meeting CIP requirements around having a government-issued identification number from the user.

Why is this valuable?

By removing the need to have users enter the full 9 digits of their SSN, FinTechs should see lower drop-off numbers during sign-up*. FinTechs will now be able to request only the last 4 digits of an applicant’s SSN before running KYC on them, meaning the applicant can be more comfortable entering less PII into the FinTech’s flow, while the FinTech will still be able to meet CIP requirements around having the full SSN for the user.

<div class="rt-btn-wrap"><a href="https://www.postman.com/synctera/workspace/synctera-public-workspace/folder/14676694-8cc8e248-7110-4c4f-abd8-05244f308d28" class="button yellow w-button">Example KYC SSN Prefill API requests and test scenarios</a></div>

Additional product updates

• KYC: Added the ‘verification_status’ field to the response from ‘/v0/verifications/verify’ so FinTechs can know the verification outcome immediately rather than having to query the outcome in another request
• Cards: Added the capability for partners to opt into participating in the transaction authorization flow by receiving and responding to gateway funding requests on every card authorization
• Cards: Added a new field to card transactions user_data.card_transaction_subtype to provide increased transaction type granularity. This will be present when fetching card transactions from the API, in all card transaction webhooks, and gateway funding requests
• Cards: Fixed a bug that resulted in refunds showing as card_transaction subtype instead of pos_refund
• Cards: Added constraint that customers have a phone number and email address in order to have a card issued, and to be able to use the card in all channels. Previously they only needed a phone number
• Cards: Added transaction merchant data enhancements for card transactions. If the card product has opted into enhanced transactions there will now be a new field in user_data.enhanced_transaction that contains cleansed/normalized transaction data**
• Cards: Added capability to issue custom photo cards

<div class="rt-btn-wrap"><a href="https://dev.synctera.com/" class="button yellow w-button">Learn more on our Developer Portal</a></div>

‍