Systems and methods for identity verification

Abstract

A method for providing know-your-client information is disclosed. The method includes receiving a user's contact information; verifying a user's eligibility; verifying a user's device; verifying a user's ID; verifying a user's background; and providing know-your-client information.

Description

SYSTEMS AND METHODS FOR IDENTITY VERIFICATIONFIELD OF THE INVENTION

[0001] This disclosure relates to identity verification.BACKGROUND

[0002] Verifying a user’s identity may require that the user provide proof when applying for bank accounts, insurance and other types of accounts, or other reasons where know-your-client rules are in effect. In doing so, the user may be asked to provide copies of identification documents (such as a driver’s license, passport, visa, proof of permanent residency, etc.), pictures of themselves, and other documents to establish their identity. However, where a user must establish their identity on multiple platforms, conventional platforms will each require the user to re-establish their identity. This results in inefficiencies arising from having to provide user identifying information multiple times on multiple platforms. Accordingly, there is a need for improved systems and methods for verifying a user’s identity.SUMMARY OF THE INVENTION

[0003] In an aspect, there is provided a method for providing know-your-client information comprising: receiving a user’s contact information; verifying a user’s eligibility; verifying a user’s device; verifying a user’s ID; verifying a user’s background; and providing know-your-client information.BRIEF DESCRIPTION OF THE DRAWINGS

[0004] The features of the invention will become more apparent in the following detailed description in which reference is made to the appended drawings wherein:

[0005] Figure 1 is a flow diagram depicting a method according to an embodiment;

[0006] Figure 2 is a flow diagram depicting a name and date of birth verification process according to an embodiment;

[0007] Figure 3 is a flow diagram depicting a nationality check according to an embodiment;

[0008] Figure 4 is a flow diagram depicting a date of entry check according to an embodiment;

[0009] Figure 5 is a flow diagram depicting an address check according to an embodiment;

[0010] Figure 6 is a flow diagram depicting an employment information check according to an embodiment;

[0011] Figure 7 is a flow diagram depicting an ID verification according to an embodiment;

[0012] Figure 8 is a flow diagram depicting a visa check according to an embodiment; and

[0013] Figure 9 is a flow diagram depicting a background check according to an embodiment.

[0014] Figure 10 is a schematic data depicting how data is transmitted between different hardware within a system according to an embodiment.DETAILED DESCRIPTION OF THE INVENTION

[0015] This application describes a method and system for securely providing a centralized identity verification where a user’s identity can be verified with multiple parties.

[0016] In an aspect of the present invention, there is provided a method and system for central identity. The method includes receiving a user contact information and creating a user profile including the user contact information. In some embodiments, the user contact information includes an email address, a phone number, or a combination thereof.

[0017] In some embodiments, the method includes sending a verification code using the user contact information, receiving the verification code from a user device, and authenticating a user device based on the verification code.

[0018] In some embodiments, the method further includes receiving user identifying information (UH) and associating the Ull with the user profile. In some embodiments, the method further includes receiving a Ull request from an API request. The Ull or a portion thereof is provided in response to the request. In some embodiments, terms and conditions associated with a use of the API request is provided, and the response to the request is provided upon theuser accepting the terms and conditions. In some embodiments, the Illi is stored in a database. In some embodiments, the Illi is encrypted for storage and in communication.

[0019] In some embodiments, the Illi includes a user’s name, birthday, nationality, address, employment information, government-issued ID information, biometric data, or a combination thereof. Biometric data is well known to persons skilled in the art and can include a recording of the user’s face, such as a video recording, a photograph, a frame capture from a video recording or a combination thereof, a fingerprint, iris or retina scan, voice print, or a combination thereof.

[0020] In some embodiments, employment information includes a user’s employment status, job title, job industry, employer name, or a combination thereof.

[0021] In some embodiments, government-issued ID information includes a type of identification, such as a driver’s license, a passport, a visa, a permanent resident card, a work permit, or combination thereof; an electronic version of the ID, such as a scan, a picture, an electronic document or a combination thereof; or a combination thereof.

[0022] In some embodiments, the method includes receiving from the user an intended use for the Illi. In some embodiments, the intended use of the verification triggers a request for Illi associated with such use. For example, the user may indicate that they are moving from one country to another. In such embodiments, the Illi can include a move date, a destination, an origin, a current location, a move reason, an immigration status, or a combination thereof. The destination and origin can, independently, include a country, a province or state, a city, or a combination thereof. In some embodiments where the move reason is for employment, education, or a combination thereof, the llll includes employer name, school name, or a combination thereof.

[0023] In some embodiments, the method includes providing one or more tasks associated with the intended use. For example, in some embodiments where the intended use is a move, in particular a move with accompanying persons (e.g. partner, dependents, etc), the method includes providing a list of tasks the user may wish to do before or when arriving after the move. Such tasks may include, for example, opening up a new bank account, finding housing, opening accounts for telecommunications (e.g. mobile phone, home internet, home phone, etc), obtaining a driver’s license, obtain health insurance, packing according to a packing list, preparing landing documents associated with arrival (e.g. biometric documents, backgroundchecks, proof of funds, medical exam results, letters of acceptance, etc). In some embodiments, particular tasks can trigger requests for particular types of UH. For example, opening a new bank account may require different Ull than finding housing.

[0024] In some embodiments, the method includes receiving user payment information and associating it with the user profile. This may, for example, allow payment information to be provided to a platform requesting Ull, where such payment information is necessary for functionality on the platform. The payment information can include, for example credit card account information, banking account information, third-party payment service account information, or a combination thereof.

[0025] With reference to FIGS 1 to 9, a particular embodiment of a method 100 for providing know-your-client information is disclosed. The method includes receiving a user’s contact information at step 110. Step 110 includes receiving a user name 112 and birthday 114.

[0026] A user’s eligibility for a service is verified at step 120. Eligibility includes a nationality check 122 which includes obtaining a user nationality 124 to determine, at 126, whether there is support for the nationality. This support may, for example, be determined by provider availability to verify underlying identification at step 170. The eligibility further includes a date of entry check 130 to verify whether the user is in their intended destination at 132, their destination province / state at 134, and their anticipated date of arrival at 136 if they did not indicate they are already in their destination at 132. If, at 138, the user indicates that they are already in their destination per the response in 132, the date of entry check 130 is complete. Otherwise, if the province / state is not supported or if it is too far from the date of entry, the check fails. Where the user is not already in the intended destination, method 100 may update a user risk score, such as on a risk engine.

[0027] The user risk score may be updated throughout the method in response to input received. In some embodiments, the risk engine will vary verifications performed and period of such verifications based on the user risk score, may differ depending on the risk score. Types of verifications scheduled by the risk engine include criminal background checks, sanction list verifications, and user name, address, occupation, contact information and whether the person is politically exposed or head of an international organization or family or close associate thereof. In some embodiments, where the user risk score is below a threshold amount, the risk engine schedules certain verifications at a lower frequency then where the user risk score isabove a threshold amount. In some embodiments, if the risk score is above a threshold amount, a trigger may be set for manual review, additional verification questions may be asked, or both.

[0028] The eligibility further includes an address check at 140 that includes receiving a user’s current address or permanent address at their origin 142. If the country is supported, a user risk score may be adjusted based on the jurisdiction of the origin at 144. Eligibility further still includes an employment information check at 150. A user’s employment status is received at 152. If the user is employed, job title 154 and industry 156 are received. Depending on the profession, the user may be determined to be ineligible or the risk score is adjusted based on the profession.

[0029] A user’s device, such as a phone number, is optionally verified at step 150. The user’s phone number is received at 152 and, depending on the support for the country code associated with the phone number, a one-time pass is sent to the phone at 154. If the OTP is received from the user’s phone at 156, the verification is successful, otherwise, the user may retry or an OTP may be resent.

[0030] The user’s ID is verified at step 160. The user takes pictures of their ID, such as a front image at 162 and a back image at 164. The user optionally takes a picture of themselves at 166. The images are sent to a verification service at 168. If the ID is one associated with the destination, visa verification at 170 may be skipped.

[0031] At step 170, the user’s visa is checked if the ID is not associated with the destination. At 172, the user selects the purpose of the account and provides proof at 172. Where the proof is uploaded, verification checks can be performed. If the document can be automatically verified, it is accepted and tagged, otherwise, it will be flagged for manual review. Where the user does not upload a governmental status document, such as a visa, work permit, or permanent residence card, but instead provides another document, such as an approval letter, an employer letter, the risk score may be updated accordingly.

[0032] The user’s background is verified at step 190. The user information submitted in prior steps may be used to conduct a background check at 192, such as presence on a sanctions list, whether they are politically exposed, or heads of international organizations, or families and close associates thereof. If the background check is successful, the background check is passed. Otherwise, the risk score is updated accordingly and may be flagged for manual review.

[0033] In some embodiments, the information received in the previous steps may be saved and sent to a third party via an API. For example, the method may include opening a third party account using the Illi. The opening a third party account may include sending, via an API, the Illi to the third party account in response to a user request. Exemplary third-party accounts include telecommunications accounts, bank accounts, insurance.

[0034] With reference to FIG 10, a schematic diagram showing an embodiment of the invention is provided. Data, such as Illi, is input by a user device, such as a mobile device, tablet, phone, or laptop. User contact information, such as that received in step 110, may be transmitted to a requesting platform to provisionally open an account, such as to open a bank account, without the know-your-client (KYC) information that may be required to fully access the services of the account. In this manner, the requester platform avoids opening multiple accounts should KYC information not be provided to it in case a document fails to be authenticated. In some embodiments, the data is only transmitted after service eligibility is confirmed based on information received at step 120.

[0035] Upon an acknowledgment from the platform that an account has provisionally been opened by the requester platform, know-your-client (KYC) information, such as the contact information, service eligibility, device verification, ID and / or visa information received from user device is sent to a KYC server for verification. The KYC server may verify the ID and / or visa information, for example, using image recognition and authentication processes. Such processes may, for example, include detection of anti-counterfeiting measures of identification and visa documents, such as watermarks, fibre placement, hologram detection, serial numbers, layouts, and the like. In some embodiments, the OTP communications are at step 150 are performed between the KYC server and the user device. Additionally, in some embodiments, background verification at step 190 may be performed by KYC server.

[0036] Once verified, the KYC server may send an acknowledgement that the ID and / or visa has been verified, such as a token, along with the authenticated KYC information, back to user device. The portions of the KYC information required to open an account with requester platform is then transmitted to the requester platform for account creation. In some embodiments, the information sent includes the acknowledgement of verification from the KYC server. In this manner, KYC information is not provided to requester platforms until after the required information has already been verified. In some embodiments, the acknowledgement ofauthentication along with the verified KYC information may be used for other purposes without a user having to re-verify their documentation.

[0037] In some embodiments, KYC information and acknowledgements of verification are stored by a database accessible to the KYC server. In some embodiments, the KYC information and acknowledgements of verification are stored by the user device. In other embodiments, only one copy and acknowledgement of verification is stored by the system, and the verified KYC information is saved and sent on an as-needed basis.

[0038] The methods and processes described above, and elements thereof, may be realized in hardware, software or any combination of hardware and software suitable for a particular application. The hardware may include a general-purpose computer, dedicated computing device, specific computing device, mobile devices, particular aspect or component of a specific computing device, or a combination thereof. The processes may be realized in one or more microprocessors, microcontrollers, embedded microcontrollers, programmable digital signal processors or other programmable device, along with internal memory, external memory, or a combination thereof. The processes may also, or instead, be embodied in an application specific integrated circuit, a programmable gate array, programmable array logic, or any other device or combination of devices that may be configured to process electronic signals.

[0039] It may further be appreciated that each method described above and combinations thereof may be embodied in a computer executable code stored on a machine readable medium, such as a non-transitory machine readable storage device that when executed, performs the elements thereof.

[0040] In the present specification, the terms “a” and “the” in singular form are, unless context clearly indicates otherwise, intended to include plural forms. Any ranges disclosed are intended to include every subrange and discrete value within such ranges.

[0041] Although the invention has been described with reference to certain specific embodiments, various modifications thereof will be apparent to those skilled in the art without departing from the spirit and scope of the invention as outlined in the claims appended hereto. Further, any terms used in the specific embodiments are for the purpose of describing such embodiments, and are not intended to limit the scope of the invention to the specific embodiments. The entire disclosures of all references recited above are incorporated herein by reference.

Claims

Claims1. A method for providing know-your-client information comprising: receiving a user’s contact information; verifying a user’s eligibility; verifying a user’s device; verifying a user’s ID; verifying a user’s background; and providing know-your-client information.

2. The method of 1, wherein the know-your-client information is authenticated know-your- client information and the providing includes an acknowledgement of verification.

3. The method of claim 2, wherein the authenticated know-your-client information that is provided is stored on a database, a user device, or both.

4. The method of claim 3, wherein the authenticated know-your-client information is configured to authenticate the user on a third party platform.

5. The method of any one of claims 1 to 4, wherein the verifying of the user’s eligibility includes determining a user location, nationality, date, destination or a combination thereof.

6. The method of claim 5, further comprising verifying residency status of the user based on the user nationality and destination.

7. The method of any one of claims 1 to 6, further comprising determining a risk score based on the user’s ID and the user’s background and withholding the providing of the know- your-client information if the risk score exceeds a threshold amount.

8. The method of any one of claims 1 to 7, wherein verifying a user’s device includes sending a challenge to a user device based on the user’s contact information and receiving, from the user device, a response to the challenge.

9. A method for providing account creation comprising: sending a user’s contact information to a requester platform; creating a temporary account on the requester platform; sending the user’s contact information and user identifying information to a know-your- client server; receiving authenticated know-your-client information from the know-your-client server; sending authenticated know-your-client information to the requester platform to convert the temporary account to a regular account.

10. The method of claim 9, wherein the authenticated know-your-client information from the know-your-client server was generated using the method according to any one of claims 1 to 8.

11. A system for generating know-your-client information comprising: a user device comprising an input for receiving user contact information and user identifying information from a user; a know-your-client server in communication with the user device, the server having a memory and instructions thereon that, when executed, cause the server to: receive the user’s contact information; verify the user’s eligibility; verify the user’s device; verify the user’s ID; verify the user’s background; and provide know-your-client information to the user device.

Images