DESC:TECHNICAL FIELD
[0001] The present subject matter relates to user onboarding and, more particularly, to systems and methods for verification of users for user onboarding.
BACKGROUND
[0002] Prior to rendering services, such as banking services, trading platform services, financial services, etc., which are offered by respective service providers, it is imperative that a verification of a user seeking to avail such a service be done by a service provider. In this regard, several mechanisms of verification of users with varying level of compliance requirements exist and a suitable mechanism may be implemented by a service provider.
[0003] With digitization, the process of user onboarding has gone digital and much of the steps of verification are being performed either online or purportedly at user’s site by on-field agents with the help of mobile computing devices, such as smartphones. For instance, user verification typically includes a step of submission of requisite document(s), such as address proof, financial statements, application form, etc. owing to the digitization, the users can nowadays scan and/or upload such documents to a server of the service provider for verification or in the alternative provide the document to the on-field agent for scanning and uploading.
[0004] While the digital onboarding techniques have made the life of users easier and less cumbersome, such digital onboarding techniques often encounter certain challenges which delay the onboarding process. For instance, one or more of documents which are uploaded by the user or the on-field agent may not meet the requisite quality standards, due to which the onboarding may be refused or paused until a better-quality upload of the document is done. As a result, the user’s onboarding experience is degraded and additional time, effort, and resources then have to be spent to re-process the verification steps for successful onboarding. This, as may be understood, results in wastage of both time and resources.
SUMMARY
[0005] This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.
[0006] In an example embodiment, a user verification system for verifying a user during user onboarding is disclosed. the system comprises a processor, a memory coupled to the processor, and a verification engine coupled to the processor. The verification engine is configured to obtain user data associated with a user requesting verification from a user device and verify the user based on the user data and communication with at least one registered server. The system further comprises a document verification engine configured to obtain one or more documents for verification of the user from the user device, perform a quality check of the one or more documents based on at least one predefined quality threshold, determine the quality check of the documents to be successful when each of the one or more documents is above the at least one predefined quality threshold.
BRIEF DESCRIPTION OF DRAWINGS
[0007] These and other features, aspects, and advantages of the present invention will become better understood when the following detailed description is read with reference to the accompanying drawings in which like characters represent like parts throughout the drawings, wherein:
[0008] FIG. 1 illustrates a network environment implementing a user verification system, according to one or more embodiments of the present subject matter;
[0009] FIG. 2 illustrates a schematic block diagram illustrating one or more components of the user verification system, according to one or more example embodiments of the present subject matter;
[0010] FIG. 3 illustrates an operation workflow of a verification engine of the user verification system, according to one or more embodiments of the present subject matter;
[0011] FIG. 4 illustrates an operation workflow of a liveness and GPS engine of the user verification system, according to one or more embodiments of the present subject matter;
[0012] FIG. 5 illustrates an operation workflow of a document verification engine of the user verification system, according to one or more embodiments of the present subject matter;
[0013] FIG. 6 illustrates an operation workflow of a risk evaluation engine of the user verification system, according to one or more embodiments of the present subject matter;
[0014] FIG. 7 illustrates another operation workflow of risk evaluation engine of the user verification system, according to one or more embodiments of the present subject matter;
[0015] FIG. 8 illustrates an operation workflow of the validation engine of the user verification system, according to one or more embodiments of the present subject matter; and
[0016] FIG. 9 illustrates an operation workflow of the document selection engine of the user verification system, according to one or more embodiments of the present subject matter.
DETAILED DESCRIPTION
[0017] For the purpose of promoting an understanding of the principles of the disclosure, reference will now be made to the embodiment illustrated in the drawings and specific language will be used to describe the same. It will nevertheless be understood that no limitation of the scope of the disclosure is thereby intended, such alterations and further modifications in the illustrated system, and such further applications of the principles of the disclosure as illustrated therein being contemplated as would normally occur to one skilled in the art to which the disclosure relates.
[0018] It will be understood by those skilled in the art that the foregoing general description and the following detailed description are exemplary and explanatory of the disclosure and are not intended to be restrictive thereof. Throughout the patent specification, a convention employed is that in the appended drawings, like numerals denote like components.
[0019] Reference throughout this specification to “an embodiment”, “another embodiment”, “an implementation”, “another implementation” or similar language means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present disclosure. Thus, appearances of the phrase “in an embodiment”, “in another embodiment”, “in one implementation”, “in another implementation”, and similar language throughout this specification may, but do not necessarily, all refer to the same embodiment.
[0020] The terms "comprises", "comprising", or any other variations thereof, are intended to cover a non-exclusive inclusion, such that a process or method that comprises a list of steps does not include only those steps but may include other steps not expressly listed or inherent to such process or method. Similarly, one or more devices or sub-systems or elements or structures proceeded by "comprises... a" does not, without more constraints, preclude the existence of other devices or other sub-systems or other elements or other structures or additional devices or additional sub-systems or additional elements or additional structures.
[0021] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure belongs. The apparatus, system, and examples provided herein are illustrative only and not intended to be limiting.
[0022] The terms “a” and “an” herein do not denote a limitation of quantity, but rather denote the presence of at least one of the referenced item. Further, the term sterile barrier and sterile adapter denotes the same meaning and may be used interchangeably throughout the description.
[0023] Embodiments of the disclosure will be described below in detail with reference to the accompanying drawings.
[0024] FIG. 1 illustrates a network environment 100 implementing a user verification system 102, according to one or more embodiments of the present subject matter. In an example, the user verification system 102 may be implemented by enterprises and/or institutions, such as banks, financial management institutes, credit lending institutes, etc., for verification of users during user onboarding. The user onboarding may be understood as a process of creation of a user account of the user with the enterprise for availing service offered by the enterprise. In some examples, the user may be previously registered with the enterprise, i.e., may have also previously created separate accounts for other services availed through the enterprise. In other cases, the user may be a new user, i.e., no previous account of the user may exist in the enterprise records. Accordingly, in either case, a validation of the user may be done, for example, by the user verification system 102 before onboarding the user.
[0025] The user verification system 102 may be embodied as a single computing device or a group of computing devices including but not limited to, a server, a remote server, a workstation personal computer, and/or the examples of the user devices mentioned herein. For instance, in some embodiments, as would be appreciated, one or more components of the user verification system 102 which would be described in detail later, may be implemented at least partially on other devices, such as the user devices mentioned herein.
[0026] In an example, the network environment 100 may include one or more user devices 104 which may enable users 106 to communicate with the user verification system 102, through a communication network 108. Examples of the user devices 104 may include, but are not limited to, a smartphone, a tablet, a laptop, a personal digital assistant, and the like. The communication network 108 may include any wired or wireless communication network including, for example, a wired or wireless local area network (LAN), personal area network (PAN), metropolitan area network (MAN), wide area network (WAN), or the like, as well as any hardware, software and/or firmware required to implement it (such as, e.g., network routers, etc.). For example, the communication network 108 may include a cellular telephone, an 802.11, 802.16, 802.20, and/or WiMax network. Further, the communication network 108 may include a public network, such as the Internet, a private network, such as an intranet, or combinations thereof, and may utilize a variety of networking protocols now available or later developed including, but not limited to TCP/IP based networking protocols.
[0027] As mentioned above, a user seeking to onboard with the enterprise may use the user device 104 for connecting with the user verification system 102. In an implementation, the user 106 may use their own user device, such as the user device 104-1, for connecting with the user verification system 102. In another implementation, a user 106-1 may connect with the user verification system 102 using the user device 104-2 of another user 106-2, for example, who may be a registered on-field agent of the enterprise. After the user 106 has connected with the user verification system 102, the user verification system 102 may perform one or more verification checks and operations before onboarding the user 106.
[0028] In an example embodiment of the present subject matter, the user verification system 102 may be configured to perform a liveness check of the user 106 by capturing multimedia associated with the user 106. Examples of the multimedia captured by the user verification system 102 may include a video of the user 106, one or more images of the user 106 with different facial expressions, and so on. By performing the liveness check, the user verification system 102 mitigates the probability of identity-based frauds. For instance, in case the user 106 is intending to onboard with the user verification system 102 using another user’s details and accordingly may use a photograph of the other user for visual checking, the user 106 would fail the verification owing to the liveness detection implemented by the user verification system 102.
[0029] Furthermore, in an example embodiment, prior to accepting one or more documents that may be uploaded by or on behalf of the user 106 for verification in connection with the onboarding, the user verification system 102 may be configured to perform a quality check of the one or more documents. Example of the one or more documents may include, but are not limited to, address proof document, bank account statement, employment history proof, identity related character certificates, etc. As would be appreciated, the one or more documents that may be required by the user verification system 102 may be based on the type of service being selected by the user.
[0030] In said example embodiment, the user verification system 102 may perform the quality check by checking whether a quality of each of the uploaded document meets a predefined quality threshold or not. Examples of the predefined quality threshold may include, but are not limited to, a legibility percentage, a font spacing, a font type, and a font size. In case an uploaded document meets the predefined quality threshold, the user verification system 102 may accept the document for further processing. In another example where an uploaded document does not meet the quality threshold, the user verification system 102 may not accept the document for further processing. In said example, the user verification system 102 may notify the user device 104 to re-upload the document or provide a better-quality document. In an example, one or more predefined quality thresholds may be implemented by the user verification system 102, depending upon the implementation.
[0031] Thus, by performing the quality check of the one or more documents, the user verification system 102 averts or reduces the possibility of a scenario where discovery of low-quality documents is made later on during the verification. For instance, the uploaded documents may be subsequently assigned to and reviewed by another user. As is known, such verification may happen after a time delay of hours or even days in some cases. Accordingly, in case a low-case document is discovered after such time delay, the process of re-capturing or re-submission of the document is again required to be performed or in some cases the verification may also be rejected and required to be started again. This, as may be gathered, results in an overall delay in the whole onboarding process. Thus, the user verification system 102 mitigates the probability of occurrence of such delays associated with the conventional onboarding processes which are time and resource consuming.
[0032] Furthermore, in an example embodiment, the user verification system 102 may be configured to create a customized document verification package based on user data associated with the user. The customized document verification package may be understood as a list of documents that may be required to be submitted by the user for verification of the user. The user data may include, but is not limited to, a name, an age, an address, an employment history, a bank statement, a credit rating, and a previous record of the user.
[0033] In said example embodiment, the user verification system 102 may be configured to obtain the user data and subsequently, based on predetermined rules and/or techniques, identify one or more documents which may be required for the verification of the user. Thus, as opposed to the conventional techniques where a fixed set of documents is required at all times for the purposes of verification, the user verification system 102 disclosed herein provides for a dynamic creation of the document verification packages based on the user data. Accordingly, a user 106 who is identified to be falling in a particular category which indicates that the user is a good candidate for the service, a smaller number of documents may be requested from the user 106. For instance, the user 106 may be a returning user and may have a clean record of previous service completions. In such a case, only a select number of documents may be identified and requested from the user 106. Further, in case the user 106 is identified to be falling in a category which indicates that the user is not a good candidate, a greater number of documents may be requested from the user 106. This will ensure that optimum security checks and verifications of the user 106 are done, prior to rendering of service to the user. As an example, the user 106 may have defaulted on several previous service accounts. Accordingly, in such cases, additional documents or a large set of documents which are required to be submitted by the user 106 may be created by the user verification system 102 to ensure adequate safety measures with regard to rendering of current service for which the user has requested for creation of account and onboarding.
[0034] Yet further, in an embodiment, the user verification system 102 may be configured to monitor the onboarding process for identifying any occurrence of probable frauds with regard to the onboarding of the user 106. To that end, the user verification system 102 may be configured to implement a set of predefined fraud detection rules throughout the whole duration of the onboarding and in case violation of any of the fraud detection rules is detected by the user verification system 102, the user verification system 102 may terminate the onboarding process. Examples of the predefined fraud detection rules may include, but are not limited to, detecting change in IP address of the user device 104, detecting receipt of the onboarding request from a blacklisted area code, detecting multiple requests within a predefined time, etc. Thus, by implementing the set of predefined fraud detection rules, the user verification system 102 provides for a robust and secure framework for ensuring fraud-free onboarding.
[0035] Thus, the user verification system 102 as disclosed herein provides for a robust and secure system for onboarding of users. As a result, probability of occurrence of fraud in relation to onboarding of users is reduced. This, as may be appreciated, also aids in minimizing the monetary losses to the enterprises which may occur as a result of such frauds. Furthermore, the overall onboarding time associated with onboarding of the user 106 may also be reduced as low-quality documents are detected at the initial point itself, thus saving on time and resources.
[0036] FIG. 2 illustrates a schematic block diagram 200 illustrating one or more components of the user verification system 102, according to one or more example embodiments of the present subject matter. In an example, the user verification system 102 may include a processor 202, memory 204 (memory device), a verification engine 206, a document selection engine 208, a liveness and GPS engine 210, a document verification engine 212, a risk evaluation engine 214, a validation engine 216, a Machine Learning (ML) and/or Artificial Intelligence (AI) engine 218, and data 220. Although, the aforementioned components have been shown as integral to the user verification system 102, as would be appreciated, one or more of the aforementioned components may be provided in other devices. Examples of such other devices may include, the user device 104.
[0037] In an example, the processor 202 may be a single processing unit or a number of units, all of which could include multiple computing units. The processor 202 may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, and/or any devices that manipulate signals based on operational instructions. Among other capabilities, the processor 202 is configured to fetch and execute computer-readable instructions and data stored in the memory 204. The memory 204 may include any non-transitory computer-readable medium known in the art including, for example, volatile memory, such as static random-access memory (SRAM) and dynamic random-access memory (DRAM), and/or non-volatile memory, such as read-only memory (ROM), erasable programmable ROM, flash memories, hard disks, optical disks, and magnetic tapes. In an example, the memory 204 may store the values of the set of predefined fraud detection rules, one or more predefined quality thresholds, predefined rules and or techniques for identifying the documents, etc. Furthermore, the memory 204 may also include data relating to execution of ML and AI techniques, image processing techniques, and other techniques as required for implementation of the operations of the user verification system 102.
[0038] The verification engine 206, the document selection engine 208, the liveness and GPS engine 210, the document verification engine 212, the risk evaluation engine 214, the validation engine 216, the Machine Learning (ML) and/or Artificial Intelligence (AI) engine 218, amongst other things, include routines, programs, objects, components, data structures, etc., which perform particular tasks or implement data types. The verification engine 206, the document selection engine 208, the liveness and GPS engine 210, the document verification engine 212, the risk evaluation engine 214, the validation engine 216, the Machine Learning (ML) and/or Artificial Intelligence (AI) engine 218 may also be implemented as, signal processor(s), state machine(s), logic circuitries, and/or any other device or component that manipulate signals based on operational instructions. Further, the verification engine 206, the document selection engine 208, the liveness and GPS engine 210, the document verification engine 212, the risk evaluation engine 214, the validation engine 216, the Machine Learning (ML) and/or Artificial Intelligence (AI) engine 218 can be implemented in hardware, instructions executed by a processing unit, or by a combination thereof. The processing unit can comprise a computer, a processor, such as the processor 202, a state machine, a logic array or any other suitable devices capable of processing instructions.
[0039] In another aspect of the present subject matter, the verification engine 206, the document selection engine 208, the liveness and GPS engine 210, the document verification engine 212, the risk evaluation engine 214, the validation engine 216, the Machine Learning (ML) and/or Artificial Intelligence (AI) engine 218 may be machine-readable instructions (software) which, when executed by a processor/processing unit, perform any of the described functionalities. The machine-readable instructions may be stored on an electronic memory device, hard disk, optical disk or other machine-readable storage medium or non-transitory medium. In one implementation, the machine-readable instructions can be also be downloaded to the storage medium via a network connection.
[0040] The data 220 serves, amongst other things, as a repository for storing data processed, received, and generated by the processor 202 during the onboarding process. Furthermore, the data 220 may include user profiles which are created for new users, historic records, such as previously created user profiles and accounts, data sent or obtained over the communication network 208, data generated by operations performed by any of the aforementioned components of the user verification system 102 during the onboarding process.
[0041] Writing further, in a non-limiting manner, one or more of the aforementioned components of the user verification system 102 may send or receive data, for example, using one or more input/output ports and one or more communication units, which have not been shown in the FIG. 2 for the sake of brevity. In an example, such ports and communication units may include one or more hardware units that support wired or wireless communication between the one or more components of the user verification system 102 and other devices, such as the user device 104 or other devices present in or connected to the communication network 108.
[0042] Details of operation of the aforementioned components of the user verification system 102 will now be defined in conjunction with the description of FIGs. 3 to 9. In an example, the ML/AI engine 218 may be configured to operate with any of the components of the user verification system 102 as described below in the description of the FIGs. 3-9.
[0043] FIG. 3 illustrates an operation workflow 300 of the verification engine 206 of the user verification system 102, according to one or more embodiments of the present subject matter. In an embodiment, the verification engine 206 may be configured to perform a verification of the user 106 seeking onboarding with the user verification system 102 of the enterprise, based on user data associated with the user. The user data associated with the user may include, for example, government recognized/registered credentials or unique identity (ID) which is associated with the user 106. The user data may further include one or more of other details such as a name, an age, a sex category, an address, of the user 106. The user data may further include other graphical elements which may be representative of the user data or may direct a reader of the graphical element to the user data. For example, the user data may include a QR code pertaining to the information of the user, and the same may be read by QR reading techniques.
[0044] The credentials and the unique ID may form part of a user profile of the user 106 which is created with a registered server of the government or any entity authorized by the government. The user profile may also include details, such as a Subscriber Identity Module (SIM), International Mobile Subscriber Identity (IMSI), and a device ID of the user device 106. In an example, an identity of the user 106 may be verified based on the credentials and/or the unique ID and the IMSI. For instance, upon providing of the IMSI, an OTP may be sent to the user device 106 from a registered server, such as a server 302-1 which is operated by an enterprise who is maintaining the user profiles. This OTP may then be used for verifying the identity of the user 106, for example, as explained below.
[0045] In an example, in case the verification engine 206 is performing an e-verification of the identity of user 106, the verification engine 206 may prompt the user 106 to enter the user data through a Graphical User Interface (GUI) being displayed on a browser application or a client application on the user device 104-1. Accordingly, the user may enter the user data which is then sent to the verification engine 206 by the user device 104-1. In an example, the verification engine 206 may implement a QR reader technique for automatically obtaining the user data upon presentation of a registered QR by the user 106. In said example, on receiving the prompt for displaying the QR code, the user 106 may display the QR code to a camera of the user device 104-1. Accordingly, the user device 104-1 may communicate the captured image of the QR code or may itself obtain the user data based on the QR code and send the user data to the verification engine 206.
[0046] In another case where the on-field agent is assisting the user 106-1 in onboarding, the user 106-1 may provide the user data details to the on-field agent 106-2, and the on-field agent 106-2 may then enter the user data details using his/her user device 104-2. Alternatively, the user 106-1 may display the QR code to the on-field agent 106-2 who may then scan the same using the user device 104-2, and the user data may then be sent to the verification engine 206.
[0047] On receiving the user data, the verification engine 206 may perform an OTP based technique for verifying the identity of the user 106 with the help of the server 302-1. The verification engine 206 may transmit the user data and a user verification request to the server 302-1. On receiving the user verification request from the verification engine 206, the server 302-1 may transmit an OTP to the user device 104-1 of the user 106. After transmitting the user data to the server 302-1, the verification engine 206 may display another GUI on the user device 104 and may prompt the user 106 to enter the OTP received on the user device 104. The OTP entered and submitted by the user 106 may then be transmitted by the user device 104 to the verification engine 206, which may then transmit the same to the server 302-1. In case the OTP transmitted by the server 302-1 matches with the OTP received by the server 302-1, the validation engine 206 may receive a message from the server 302-1 indicating that the verification of the user 106 is successful. In the alternate, i.e., where the OTPs do not match, the server 302-1 may indicate in the message that the verification was unsuccessful. In case the verification of the user is deemed to be unsuccessful, the verification engine 206 may terminate the onboarding process.
[0048] In an example, the verification engine 206 may be configured to perform an additional verification of the identity of the user, for example, based on the user data obtained from the user 106. In said example, after the first verification is successful, the verification engine 206 may make use of other user data, for example, name, age, address of the user 106 for performing a second verification of the identity of the user 106 and may communicate with another server, say, a second server 302-2 in this regard. The second server may be another registered server which may include user profiles and details of users. In said example, the verification engine 206 may transmit the user data to the second server 302-2 and the second server may accordingly make a comparison of the received user data with the user data associated with the user 106, as existing in its internal records. On a successful match, the verification engine 206 may receive a message from the second server 302-2 indicating that the verification of the identity of the user 106 is successful. Alternatively, in case of an unsuccessful match, the verification engine 206 may receive a message from the second server 302-2 indicating that the verification of the identity of the user 106 is unsuccessful. Accordingly, in such a case the verification engine 206 may terminate the onboarding process.
[0049] FIG. 4 illustrates an operation workflow 400 of the liveness and GPS engine 210, hereinafter interchangeably ‘engine 210’, of the user verification system 102, according to one or more embodiments of the present subject matter. In an example embodiment, the engine 210 may be configured to perform a liveness check of the user 106 based on multimedia associated with the user 106. As would be appreciated, the engine 210 may perform the liveness check of the user 106 using either the user device 104-1, i.e., the user 106’s own user device, or using the user device 104-2, i.e., the on-field agent 106-2’s user device. As used herein, the liveness check may be understood as implementation of one or more techniques to detect if it is actually the user 106 who is performing the onboarding process.
[0050] In an example, for performing the liveness check, the engine 210 may be configured to request the user device 104 to capture and transmit multimedia data associated with the user. For instance, in an example, the request may include a request to record a video of the user 106 in real-time. The request may specify the interval of the video and/or a type, such as mp4 etc., of the video. In said example, the user device 104 may capture a video of the user 106 for the duration specified in the request along with a timestamp and may accordingly transmit the captured video and the timestamp as the multimedia data to the engine 210. On receiving the multimedia data from the user device 104, the engine 210 may accordingly determine whether the video and the time stamp are within a predefined interval from a current time at which the video and the timestamp is received at the engine 210. This predefined interval may be configured by the engine 210 based on an estimate time required for uploading a video of the specified predefined length and/or type, as per a network condition. The network condition may be determined in real-time by the engine 210, for example, by communicating with the respective regional communication servers, such as a server 402, or may be determined based on historic data of network conditions which may be obtained by the engine 210 from the server 402. For this purpose, the engine 210 may transmit a request to the server 402. The request may include at least one of: a request to provide real time network conditions or a request to provide historic data of the network conditions. Based on the request, the server 402 may transmit the requested information to the engine 210, and the engine 210 may then make the above determination. In case the video and the time stamp are received within the predefined interval, the engine 210 may deem the liveness check as successful. Alternatively, the engine 210 may deem the liveness check to be unsuccessful.
[0051] In another example, the engine 210 may be configured to transmit one or more example facial expressions to the user device 104. The engine 210 may subsequently request the user device 104 to capture one or more images of the user 106 performing these facial expressions as the multimedia data. Based on the request, the user device 104 may display the facial expressions to the user 106 on a screen of the user device 104 and accordingly capture an image using a camera of the user device 104, say after a predetermined time period after displaying the facial expression, and store the same as multimedia data. This multimedia data is then sent by the user device 104 to the engine 210. The multimedia data including the captured one or more images may be received by the engine 210 from the user device 104. In case the facial expressions in the one or more images match with the one or more example facial expressions transmitted to the user device 104, the engine 210 deems the liveness check to be successful. Alternatively, the engine 210 deems the liveness check to be unsuccessful. In an implementation, the one or more facial expressions transmitted to the user device 104 may be dynamically selected in real-time to ensure the integrity of the liveness check. As would be appreciated, other techniques for performing the liveness check may be implemented by the engine 210.
[0052] Furthermore, in an example embodiment, the engine 210 may be configured to perform a GPS location check of the user device 104 of the user 106. In said embodiment, the engine 210 may be configured to request the user device 104 to capture an image of the user 106 in real time and link the current GPS coordinates of the user device 104 with the captured image. The user device 104 may accordingly capture an image of the user 106 and may link the real-time GPS coordinates of the user device 104 with the captured image. The engine 210 may subsequently receive the captured image along with the details of the current GPS coordinates of the user device 104 which were linked with the captured image, from the user device 104. The engine 210 may then perform a comparison of the received GPS coordinates and the address of the user 106, as provided in the user data to ascertain whether the user 106 is actually present at the address. In this regard, the engine 210 may communicate with a GPS server 404 to obtain the address corresponding to the GPS coordinates. In case the GPS coordinates match with the address of the user 106, the engine 210 may deem the GPS location check to be successful. Alternatively, the engine 210 may deem the GPS location check to be unsuccessful.
[0053] FIG. 5 illustrates an operation workflow 500 of the document verification engine 212, hereinafter interchangeably ‘engine 212’, of the user verification system 102, according to one or more embodiments of the present subject matter. In an example embodiment, prior to accepting one or more documents that may be uploaded by the user 106 for verification in relation to the onboarding, the engine 212 may be configured to perform a quality check of the one or more documents. As would be appreciated, the engine 210 may receive the one or more documents from the user 106 using either the user device 104-1, i.e., the user 106’s own user device, or using the user device 104-2, i.e., the on-field agent 106-2’s user device. In said example embodiment, the engine 212 may be configured to perform the quality check of the one or more documents based on at least one predefined quality threshold. Examples of the one or more documents may include, but are not limited to, an address proof document, a bank account statement, employment proof document, etc. Examples of the predefined quality threshold may include, but are not limited to, a legibility percentage of the content of the document, a font type, a font size, a line spacing, a notarization stamp marker, etc.
[0054] As may be understood, the predefined quality thresholds may be based on one or more parameters of a document, and said parameters may be used for the quality check of the document. For example, a text document may have several parameters, such as a size of the font, a legibility percentage of the document, a type of the font, and a line spacing of the lines. These parameters may be further based on a particular category of document. For instance, in case the document is a legal type of document of a particular kind, the parameter may be a signature or a stamping of the document and the threshold in this case may be, whether the document is signed or not, stamped or not, etc.
[0055] In an example, for performing the quality check of the documents, the engine 212 may first determine a type of document which is to be assessed for quality check. Subsequently, the engine 212 may determine at least one parameter of the document which is to be used for the quality check and may accordingly select at least one predefined quality threshold which may be implemented for performing the quality check of the document under evaluation. The selection of the at least one predefined quality threshold by the engine 212 may be done based on the at least one parameter. As an example, in case the document is an address proof document, the engine 212 may determine that the document may be determined based on the parameters of legibility and text size. Accordingly, the engine 212 may select and implement a font size quality threshold and a legibility percentage threshold, for performing the quality check of the address proof document.
[0056] In an example, after the engine 212 has determined the at least one predefined quality threshold which is to be implemented for performing the quality check of a document under evaluation, the engine 212 may determine a value of the at least one parameter based on one or more predetermined techniques. For instance, in the above example, the engine212 may be configured to select an appropriate computer vision and/or machine learning technique for determining the legibility percentage and the font size. More particularly, for performing the quality check of the address proof document, the engine 212 may select an Optical character recognition (OCR) technique. Herein, the engine 212 may implement a text detection model to detect the bounding boxes around possible texts. Subsequently, the engine 212 feeds the bounding boxes to a text recognition model, for example Tensor flow, to determine specific characters inside the bounding boxes. Subsequently, the engine 212 may determine a legibility percentage and/or a font size of the characters and may compare them with the respective thresholds for performing the quality checks.
[0057] In case the result of the analysis is that the document meets the predefined quality threshold, i.e., the value of the parameter is equal to or greater than the corresponding threshold, the engine 212 may be configured to deem the document verification of that document as successful. Alternatively, the engine 212 may deem the document verification of that document unsuccessful when the value of the parameter is less than the threshold. In this case, the engine 212 may request the user 106 to re-upload the document or provide alternate document. In case the user 106 subsequently is not able to provide a document which meets the threshold, the engine 212 may then terminate the onboarding process.
[0058] As would be appreciated, the engine 210 may perform the liveness check of the user 106 using either the user device 104-1, i.e., the user 106’s own user device, or using the user device 104-2, i.e., the on-field agent 106-2’s user device,
[0059] FIG. 6 illustrates an operation workflow 600 of the risk evaluation engine 214, hereinafter interchangeably ‘engine 214’, of the user verification system 102, according to one or more embodiments of the present subject matter. In an example embodiment, the engine 214 may be configured to monitor the onboarding of the user 106 for identifying any occurrence of possible fraud with regard to the onboarding of the user 106. As would be appreciated, the engine 214 may perform the monitoring based on the interactions with the user device 104, which may be a user device of the user 106 or may be the user device 104-2 of the on-field agent 106-2. In said example embodiment, the engine 214 may perform the monitoring based on a set of fraud detection rules. Without limitation, the set of fraud detection rules may include rules that are based on, for example, an IP address of the user device 104, number of requests received by the user verification system 102 in a given predefined time period, a list of blacklisted area codes, etc. For example, the set may include a rule that if the IP address of the user device 104 changes more than a predefined number of times during the onboarding process, determine the onboarding as a case of fraud. In another example, the set may include a rule that if more than x number of requests for onboarding within y duration from the user device 104 and/or based on same user credentials is received by the user verification system 102, determine the onboarding as a case of fraud.
[0060] In an example, the engine 214 may implement the set of fraud detection rules throughout the duration of the onboarding for detection of occurrence of any possible fraud. In case the engine 214 detects violation of any of the fraud detection rules that are being implemented by the engine 214 during the onboarding of the user 106, the engine 214 may immediately terminate the onboarding process or may halt the process.
[0061] FIG. 7 illustrates an operation workflow 700 of the engine 214 of the user verification system 102, according to one or more embodiments of the present subject matter. In an example embodiment, the engine 214 may be configured to determine a risk category of the user 106 based on the user data provided by the user. In an example, the engine 214 may be configured to provide the user data received from the user device 104 to a server 702 of a credit management enterprise. The server 702, based on the user data, may compile a record of the user 106’s previous and current running accounts and may determine a credit score of the user 106, and may transmit the record including the credit score to the engine 214. On receiving the record from the server 702, the engine 214 may be configured to perform a risk evaluation analysis based on the record of the user 106 and accordingly classify the user in one of a plurality of risk categories. Examples of the risk categories may include, but are not limited to, low risk, medium risk, and high risk.
[0062] The risk evaluation analysis, in an example, may be performed based on a trained model. In said example, the trained model may be previously trained based on historic data, which may include but is not limited to, a plurality of credit scores of a plurality of users, records of the plurality of users, information about successful/unsuccessful completion of account on time or as per any of predefined account parameters and conditions by the users, etc. As would be understood, a correlated and weighed trained model based on the aforesaid data may be prepared which is capable of taking a credit score of a user as input, and provide a risk evaluation report 704, as an output. The risk evaluation report may include the risk category of the user 106, as determined by the trained model. Thus, the engine 214 may implement the trained model as explained herein, to determine the risk category of the user 106. Furthermore, in an example, the engine 214 may update the user data to include the credit score, details of other accounts, and the risk category in the user data.
[0063] In an example, the engine 214 may be configured to notify a user, such as an administrator about the risk category of the user 106, in case the risk category is other than ‘low risk’ category. In such a case, the engine 214 may halt the onboarding process and may proceed forward only after getting an approval input from the administrator.
[0064] FIG. 8 illustrates an operation workflow 800 of the validation engine 216, hereinafter interchangeably ‘engine 216’ of the user verification system 102, according to one or more embodiments of the present subject matter. In an example embodiment, the engine 216 may be configured to validate whether a payment account of the user 106 is active or not based on user data provided by the user 106. The user data, in said example, may include the details of a payments account, such as a bank account or a digital wallet account, of the user 106. In an example, the user 106 may provide the user data through the user device 104-1 or through the user device 104-2. On receiving the user data, the engine 216 may be configured to transmit the user data to a server 802 of a payment institution with which the user 106’s payments account is registered along with a request to verify if the payment account is active or not. Accordingly, the server 802 may check the records and transmit an account status to the engine 216. In case the account status indicates that the payment account of the user 106 is active, the engine 216 may deem the validation of the user account as successful. In case the account status indicates that the payment account of the user 106 is inactive, the engine 216 may deem the validation of the user account as unsuccessful. In this case, the engine 214 may terminate the onboarding or halt the onboarding.
[0065] FIG. 9 illustrates an operation workflow 900 of the document selection engine 208, hereinafter interchangeably ‘engine 208’ of the user verification system 102, according to one or more embodiments of the present subject matter. In an example embodiment, the engine 208 may be configured to create a customized document verification package 902 based on the user data associated with the user 106. The customized document verification package 902 may be understood as a set of documents that the user 106 may be required to submit for verification during the onboarding process.
[0066] In said example embodiment, the engine 208 may be configured to obtain the user data of the user 106 and subsequently analyze the user data based on one or more predetermined rules. The predetermined rules may be a set of rules which may be implemented either in a particular order on an incremental checkpoint basis or in any order based on implementation basis. In the case of incremental checkpoint basis, the user 106’s candidature may be evaluated for next rule only after the user 106 has cleared the current rule.
[0067] As an example, the set may include rules such as: Is the user 106 a returning user, are there any previously available records for the user 106, is the credit score of the user 106 above predefined credit score threshold, is the date of credit report within a predefined time interval from a current date, has the user 106 submitted any bank accounts, is the average bank balance of the user above a threshold balance, etc., has the user timely cleared the previous accounts, is the user 106’s risk category low, medium or high, etc. Thus, these rules may be implemented in any order and depending upon a determination made with respect to these rules based on the user data, the engine 208 may identify the one or more documents that may be required for verification of the user 106 during the onboarding process. Thus, for a user having good credit score and/or who is a returning customer, a smaller number of documents may be requested. Likewise, in case a customer is a first customer and has a high-risk category, the engine 208 may deem that a greater number of documents are required. Accordingly, the engine 208 creates the document verification package 902 and stores its details in the memory 204 and/or data 220.
[0068] Thus, in an example, the engine 212 may obtain the document verification package 902 from the storage and may transmit details of the one or more documents which may be required for the verification of the user to the user device 104. Accordingly, the user device 104 may prompt the user 106 to provide only those documents that are listed in the document verification package 902. Thus, by customizing the document verification package 902, the engine 208 reduces the cumbersome process of verification for the user 106.
[0069] In an example use case, a user who is seeking to create an account with an enterprise, such as a bank or a loan lending enterprise may transmit a request to the user verification system 102 using the user device 104. In said use case, the user verification system 102 may first perform the verification operation as described above. Once the user is verified, the user verification system 102 may then perform the liveliness and GPS check of the user. Once the same is successful, the user verification system may perform the credit risk evaluation of the user and may update the user data accordingly. Subsequently, the user verification system 102 may create a customized document verification package based on the updated user data. The user verification system 102 subsequently communicates the details of the document verification package to the user. Accordingly, only those documents which are deemed necessary for the verification are obtained from the user. On receiving these documents, the user verification system 102 may perform a quality check of the documents and may do a validation check to determine if the payments account of the user is active or not. Throughout the above onboarding process, the user verification system 102 may monitor the onboarding for detection of occurrence any fraud.
[0070] As would be appreciated, the above operation flow described in the above example use case is no way intended to limit the scope of the subject matter to the described flow. Any modification in the order of performance of the above operations may be done and is intended to be within the scope of the described subject matter.
[0071] Thus, the user verification system 102 as disclosed herein provides for a robust and secure system for onboarding of users. As a result, probability of occurrence of fraud in relation to onboarding of users is reduced. Amongst other advantages, the overall onboarding time associated with onboarding of the user 106 may also be reduced as low-quality documents are detected at the initial point itself, thus saving on time and resources.
[0072] Benefits, other advantages, and solutions to problems have been described above with regard to specific embodiments. However, the benefits, advantages, solutions to problems, and any component(s) that may cause any benefit, advantage, or solution to occur or become more pronounced are not to be construed as a critical, required, or essential feature or component of any or all the claims.
[0073] While specific language has been used to describe the disclosure, any limitations arising on account of the same are not intended. As would be apparent to a person in the art, various working modifications may be made to the apparatus in order to implement the inventive concept as taught herein.

CLAIMS:

WE CLAIM:

1. A user verification system for verifying a user during user onboarding, the system comprising:
a processor;
a memory coupled to the processor;
a verification engine coupled to the processor and configured to:
obtain user data associated with a user requesting verification from a user device;
verify an identity of the user based on the user data and communication with at least one registered server maintaining user records; and
deem the verification of the identity of the user as successful based on a verification message received from the at least one registered server; and
a document verification engine coupled to the processor and configured to:
obtain one or more documents for verification of the user from the user device, when the verification of the user is deemed as successful;
perform a quality check of the one or more documents based on at least one predefined quality threshold; and
determine the quality check of the documents to be successful when each of the one or more documents is above the at least one predefined quality threshold used for verifying the document.

2. The system as claimed in claim 1, wherein, for performing the quality check of the one or more document, the document verification engine is configured to:
identify a type of the document under evaluation for quality check; and
determine at least one parameter based on which the document is to be evaluated, based on the type of the document;
select the at least one predefined quality threshold from one or more predefined quality thresholds based on the at least one parameter;
determine a value of the at least one parameter based on one or more predetermined technique;
compare the value of the at least one parameter of the document with the selected at least one predefined quality threshold;
determine that the document meets the at least one predefined quality threshold, when the value of the at least one parameter of the document is equal to or greater than the at least one predefined quality threshold; and
determine that the document fails to meet the at least one predefined quality threshold, when the value of the at least one parameter of the document is less than the at least one predefined quality threshold.

3. The system as claimed in claim 2, wherein the one or more predefined quality thresholds comprises a legibility percentage, a font size, a font type, and a line spacing.

4. The system as claimed in claim 1, wherein the system further comprises a liveness and GPS engine coupled to the processor, wherein the liveness and GPS engine is configured to:
obtain multimedia data and location data associated with the user device, from the user device; and
perform a liveliness check of the user based on the multimedia data; and
perform a GPS location check of the user based on the location data received from the user device.

5. The system as claimed in claim 4, wherein, for performing the liveness check of the user, the liveness and GPS engine is further configured to:
transmit a request to the user device for capturing and transmitting the multimedia data, wherein the request indicates at least one of a length of a video to be captured in real-time;
receive the multimedia data comprising the video and a timestamp associated with the video from the user device;
determine whether the multimedia data is received within a predetermined interval of a current time at which the multimedia is received; and
perform the liveliness check of the user based on the multimedia data when it is determined that the multimedia data has been received within the predetermined interval of time.

6. The system as claimed in claim 5, wherein the predetermined interval of time is determined based on network condition data obtained from a communication server, wherein the network condition data comprises data indicative of at least one of: real-time network conditions and historic network conditions.
7. The system as claimed in claim 1, wherein the system further comprises a document selection engine coupled to the processor, wherein the document selection engine is configured to:
obtain the user data associated with the user;
identify one or more documents that are required for the verification of the user based on an analysis of the user data using one or more predetermined rules;
create a customized document verification package including details of the identified one or more documents for the verification of the user.

8. The system as claimed in claim 7, wherein the document verification engine is configured to:
transmit a request to the user device for providing the one or more documents based on the customized document verification package; and
obtain the one or more documents that are specified in the customized document verification package from the user device.

9. The system as claimed in claim 7, wherein the user data comprises information indicative of a risk category associated with the user, and wherein the document selection engine is configured to identify the one or more documents based on the risk category associated with the user, wherein a number of documents identified for a high-risk category user is greater than a number of documents identified for a low-risk category user.

10. The system as claimed in claim 1, wherein the system comprises a risk evaluation engine coupled to the processor and configured to:
monitor the onboarding of the user from start to end based on one or more fraud detection rules;
detect violation of at least one fraud detection rule; and
terminate the onboarding of the user, in response to detection of violation of the at least one fraud detection rule.