Patent Grant
10956916
The present invention is directed generally to systems and methodologies associated with enabling identity verification and more particularly to systems and methodologies which employ machine learning to enhance the systems and models for verifying the identity of users attempting to engage in various transactions.
In today's business environment, almost all businesses have an online presence. A great majority of these businesses permit their customers to conduct transactions online. These transactions almost always involve either a financial component or otherwise require a trust-based element. For example, when a customer purchases a good or service, it is critical to determine that the person (or machine) initiating and conducting the transaction is who they say they are. This identity verification is required to ensure that the form of payment (e.g. credit card) is authorized for use by the purported purchaser. If the purchaser cannot be verified, then a variety of undesirable results can occur, such as chargebacks and other revenue losses.
Even when there is no financial component to a transaction, negative consequences can still result if one of the participants is not who they say they are. For example, businesses may offer other types of online services which provide access to data, access to sensitive systems or resources or the ability to conduct non-financial transactions impacting the operation of the business. It is necessary to do whatever is possible to ensure that the person, entity or machine seeking to conduct these types of interactions are who they say they are and that their purported activity is not fraudulent.
Various fraud detection and identity verification methodologies and related systems for implementing the same exist. While these offerings are generally helpful and effective, there exists a need for novel approaches to the problem of verifying identities and preventing fraud in connection with online activities.
In connection with identity verification in particular, various regulatory schemes exist under which transaction processors and other regulated entities must comply with specific requirements associated with potential transactions. One such regulatory framework is often referred to as know your customer (KYC). The KYC requirements dictate that financial institutions must verify consumer identities before allowing potential customers to engage in most financial transactions. These policies and requirements have generally been expanding both in the United States and globally. They are designed to address corruption, terrorist financing, money laundering and various other financial crimes.
KYC policies and requirements have become an important tool for financial institutions to prevent illegal transactions and to perform identity verification. Typically, KYC procedures require the financial institution to collect some basic personal information about their customer such as name, social security number, date of birth and/or residential address. Once this data is collected, it can be compared against lists of individuals known for corruption, individuals subject to sanctions and individuals known to be at high risk for committing financial crimes. In addition, the submitted data can be checked for internal consistency between its various elements. Based on these checks and others, the financial institution can then apply its own risk assessment metrics to the results to determine if the customer should be permitted to establish a relationship with the company and/or if a specific transaction should proceed.
In traditional approaches to identity verification, static databases are employed for the assessment of online transactions. However, these approaches suffer from a number of drawbacks. For one, the data sets that make up the model require frequent updates to remain effective. In a static database system, these updates may require manual intervention as updated data arrives, and there is often a lag between the time that new data is required and the time that it is implemented to make KYC decisions. This lag often results in undesirable outcomes, such as inaccurate and error-prone identity verification results which drive bad decision making in terms of which transactions are permitted and which are not.
Financial institutions generally make money when they bring in new customers who process legitimate transactions. Therefore, financial institutions want to limit as much as possible, rejections of customers who really are who they say they are. This is commonly termed false-positive declines. Outdated databases are a leading cause of these false positives.
Similarly, false negative declines—cases in which an institution fails to prohibit a customer that does not satisfy KYC from transacting, are a significant problem. In addition to false negatives subjecting an institution to potentially fraudulent transactions, they may even cause the institution to be punished for running afoul of the regulatory framework.
Yet another concern associated with current identity verification systems is the impact that they can have on the user experience. In some cases, the process can slow down the transaction and/or add additional confusion for the customer. This can result in abandonment of the transaction and possibly loss of revenue and/or other negative impacts to the customer relationship specifically and/or the business in general. Online merchants and other businesses which conduct and offer online transactions are seeking a seamless experience where identity verification activities occur in the background and are essentially invisible to the user.
Due to the inherent operational characteristics of existing systems, both false positives and false negatives occur at an undesirable rate. This results in preventing transactions that should be permitted to occur and permitting transactions to occur when they should not be permitted. Both situations harm businesses and their customer relations.
A primary objective of the invention disclosed herein is a system and methodology which addresses the drawbacks of the prior art by employing novel machine learning techniques in order to periodically update and supplement a set of identity verification databases that underlie KYC determinations. The system and methodology of the present invention periodically receives updated identity data from third-party sources and uses customer logic input to update the model used in making KYC determinations. The system of the present invention further updates and optimizes the identity verification databases and selectively deploys them in a production environment, without requiring any human intervention, such that identity verification is incrementally improved over time as more identity data and customer logic input is provided to the system.
While the present invention is described in the context of making identity verification decisions based on the likelihood of an individual attempting to engage with a company actually being who they say they are, the invention is not necessarily limited thereto. Rather, the teachings of the present invention can also be applied in any cases where it is desirable to use an identity determination to provide guidance in selectively allowing, rejecting or restricting online transactions.
Another object of the present invention is to provide a system which allows KYC determinations to be made based on known identity data as well as identity clusters derived from that data. Over time, and as new known identity data and customer feedback is provided to the system and new identity clusters are developed based thereupon, the system becomes iteratively more accurate in providing data to assist customers in making identity verification decisions. Because machine learning is employed, much of the human involvement which was required in prior art systems can be eliminated or reduced.
The system and methodology of the present invention operate, in one embodiment, to provide a cloud-based application through which an external system can make calls/requests, such as through APIs or other machine-to-machine protocols, for scoring data for KYC determinations based on information provided in connection with the calls/requests. In preferred embodiments, the information provided to the system of the present invention when calls are made may include personal information which may include the user's name, physical address, social security number, date of birth and/or other information. Also, in preferred embodiments, the system of the present invention returns a series of identity verification scores which are used by the calling system to make an identity verification decision, such as whether or not to permit the opening of a new credit card account. Reason codes may also be returned to the calling system. These reason codes further quantify the basis for the identity verification scores generated by the system of the present invention as more fully described herein.
In preferred embodiments of the present invention, the identity verification scores are derived from the mapping of the received identity data as against the identity clusters generated by the system of the present invention. The calling system can then use the identity verification scores to make a KYC decision based upon criteria that have been pre-determined through the configuration of the calling system. In some cases, manual human intervention may be used to make or assist in making the identity verification decision. The determination as to whether human intervention is needed can be based on a number of factors including the identity verification scores, the type of transaction being attempted and/or various aspects of the data associated with the individual or entity attempting the transaction, as such data is known to either or both of the system of the present invention and/or the calling system.
The system and methodologies of the present invention also periodically receive feedback data from some or all of the calling systems, with respect to each of the prior KYC requests. In preferred embodiments, this includes whether or not the transaction was authorized or valid.
In preferred embodiments, the machine learning pipeline of the present invention triggers automatically when a new data file is received from a third-party vendor. These files are made available to the system of the present invention at varying times and at different frequencies. Upon receipt of these files, the system preferably operates to standardize and normalize the file format so that it is consistent with other files used by the system. In addition, these files are compared with previously received files to ensure consistency. After this, file cleanup is performed as well as additional data-quality checks.
Verification model development is an ongoing process as updated and new data files are received from time to time. Data records are clustered using the set of available data in the data files such that identity data associated with each identity is grouped together to assist in verification determinations. As new clusters of identity are generated, these new clusters are compared against the active version of the identity clusters to assess whether or not performance has improved. The new clusters are moved to replace the active version only when a threshold improvement is made. This generally requires that the auto approvals (which reflect automated identity verification by transacting entities without human intervention) for customer KYC inquiries are determined by established statistical measures to be improved as against the previous active model as determined by established statistical measures.
When KYC queries are received from calling systems, the system of the present invention will then perform data transformation, as more fully described herein, including through the use of various natural language processing techniques, to ensure that the queries are formatted in a manner allowing the machine learning algorithms access to the data, so as to make KYC determinations according to the teachings herein. The data associated with the queries is then mapped against the active version of the identity cluster model. The resulting outcome of this mapping is a set of scores associated with each aspect of the queried data, reflecting the likelihood of an identity verification match. These scores, along with a set of reason codes reflecting the basis for the determination, are then returned to the querying system, which then uses the data to make an identity verification determination either automatically or with manual human intervention, or via some combination of both.
The present disclosure will now be described in terms of various exemplary embodiments. This specification discloses one or more embodiments that incorporate features of the present embodiments. The embodiment(s) described, and references in the specification to “one embodiment”, “an embodiment”, “an example embodiment”, etc., indicate that the embodiment(s) described may include a particular feature, structure or characteristic. Such phrases are not necessarily referring to the same embodiment. The skilled artisan will appreciate that a particular feature, structure or characteristic described in connection with one embodiment is not necessarily limited to that embodiment but typically has relevance and applicability to one or more other embodiments.
In the several figures, like reference numerals may be used for like elements having like functions even in different drawings. The embodiments described, and their detailed construction and elements, are merely provided to assist in a comprehensive understanding of the present embodiments. Thus, the present embodiments can be carried out in a variety of ways and do not require any of the specific features described herein. Also, well-known functions or constructions are not described in detail since they would obscure the present embodiments with unnecessary detail.
The description is not to be taken in a limiting sense but is made merely for the purpose of illustrating the general principles of the present embodiments, since the scope of the present embodiments are best defined by the appended claims.
It should also be noted that in some alternative implementations, the blocks in a flowchart, the communications in a sequence-diagram, the states in a state-diagram, etc., may occur out of the orders illustrated in the figures. That is, the illustrated orders of the blocks/communications/states are not intended to be limiting. Rather, the illustrated blocks/communications/states may be reordered into any suitable order, and some of the blocks/communications/states could occur simultaneously.
All definitions herein should be understood to control over dictionary definitions, definitions in documents incorporated by reference, and/or ordinary meanings of the defined terms.
The indefinite articles “a” and “an,” as used herein and in the claims, unless clearly indicated to the contrary, should be understood to mean “at least one.”
The phrase “and/or,” as used herein in the specification and in the claims, should be understood to mean “either or both” of the elements so conjoined, i.e., elements that are conjunctively present in some cases and disjunctively present in other cases. Multiple elements listed with “and/or” should be construed in the same fashion, i.e., “one or more” of the elements so conjoined. Other elements may optionally be present other than the elements specifically identified by the “and/or” clause, whether related or unrelated to those elements specifically identified. Thus, as a non-limiting example, a reference to “A and/or B”, when used in conjunction with open-ended language such as “comprising” can refer, in one embodiment, to A only (optionally including elements other than B); in another embodiment, to B only (optionally including elements other than A); in yet another embodiment, to both A and B (optionally including other elements); etc.
As used herein in the specification and in the claims, “or” should be understood to have the same meaning as “and/or” as defined above. For example, when separating items in a list, “or” or “and/or” shall be interpreted as being inclusive, i.e., the inclusion of at least one, but also including more than one, of a number or list of elements, and, optionally, additional unlisted items. Only terms clearly indicated to the contrary, such as “only one of” or “exactly one of,” or, when used in the claims, “consisting of,” will refer to the inclusion of exactly one element of a number or list of elements. In general, the term “or” as used herein shall only be interpreted as indicating exclusive alternatives (i.e. “one or the other but not both”) when preceded by terms of exclusivity, such as “either,” “one of,” “only one of,” or “exactly one of” “Consisting essentially of,” when used in the claims, shall have its ordinary meaning as used in the field of patent law.
As used herein in the specification and in the claims, the phrase “at least one,” in reference to a list of one or more elements, should be understood to mean at least one element selected from any one or more of the elements in the list of elements, but not necessarily including at least one of each and every element specifically listed within the list of elements and not excluding any combinations of elements in the list of elements. This definition also allows that elements may optionally be present other than the elements specifically identified within the list of elements to which the phrase “at least one” refers, whether related or unrelated to those elements specifically identified. Thus, as a non-limiting example, “at least one of A and B” (or, equivalently, “at least one of A or B,” or, equivalently “at least one of A and/or B”) can refer, in one embodiment, to at least one, optionally including more than one, A, with no B present (and optionally including elements other than B); in another embodiment, to at least one, optionally including more than one, B, with no A present (and optionally including elements other than A); in yet another embodiment, to at least one, optionally including more than one, A, and at least one, optionally including more than one, B (and optionally including other elements); etc.
It will be understood that, although the terms “first”, “second”, etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another. For example, a first element could be termed a second element, and, similarly, a second element could be termed a first element, without departing from the scope of example embodiments. As used herein, the term “and/or” includes any and all combinations of one or more of the associated listed items. As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise.
The word “exemplary” is used herein to mean “serving as an example, instance, or illustration.” Any embodiment described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other embodiments. Additionally, all embodiments described herein should be considered exemplary unless otherwise stated.
With reference now to
IVSS 100 preferably includes an identity verification engine (IVE) 300, which itself is comprised of a number of modules as discussed further herein. IVE 300 operates to generate scores associated with identity verification determinations based on received input. These scores are generated in response to requests originating from clients 220a, 220b, . . . 220n. IVSS 100 may be accessed through the internet, or any other private or public network, by one or more clients 220.
Each of clients 220 may be personal computers, laptops, handheld computing devices (such as smartphones or tablets) or any other device capable of providing the required connectivity and display. In some embodiments, client 220 may be a computing application operated by a customer which requires identity verification guidance to process transaction requests. For example, client 220 may be an application or set of applications operated by a financial institution which processes requests for new account openings and/or for new credit cards made by customers of that financial institution.
Clients 220 interact with IVSS 100 such that data may be communicated between them via application interface 120 and such that IVSS 100 may process identity verification score requests made by clients 220. Application interface 120 may comprise one or more application programming interfaces (APIs) that permit applications associated with client 220 to communicate with IVSS 100.
Also shown in
Raw databases 200 may also be present according to the teachings of the present invention. Raw databases 200 may comprise one or more external databases, data sets, systems, applications, rules bases and/or other sources of data which are used by IVSS 100 to generate identity verification scores and/or to generate and/or update the cluster model used by IVSS 100 as further described herein. By way of example, raw databases 200 may comprise credit reporting databases, demographic databases, reported and known fraud data, financial transaction data, physical address data, phone data, credit inquiry data, date-of-birth information, utility data and marketing data as well as other sources of data useful to IVSS 100 in updating the identity cluster models according to the teaching of the present invention. More details on the types of data and related databases which may be available to IVSS 100 are provided below. As noted above, and in preferred embodiments, raw databases 200 may be third-party applications which periodically provide identity related data to IVE 300 for updating cluster models. This data may be in formats and frequencies as may be determined by the third-party vendors, the operator of IVSS or both.
Returning now to the specific components of IVSS 100, IVSS 100 may include various components for generating scores which are used to make a binary decision on identity verification. In one embodiment, these components may include application interface 120 (described above), active identity clusters 410, pending identity clusters 420 and the various components of IVE 300. Each of these components and their associated functionality are more fully described below.
IVSS 100 may reside on one or more physical servers. These servers may include electronic storage, one or more processors, and/or other components. The servers may also include communication lines or ports to enable the exchange of information with a network and/or other computing platforms. The servers may include a plurality of hardware, software and/or firmware components operating together to provide the functionality attributed herein to IVSS 100.
Electronic storage associated with the servers may comprise non-transitory storage media that electronically stores information. The electronic storage media of electronic storage may include system storage that is provided integrally (i.e., substantially non-removable) with servers and/or removable storage that is removably connectable to the servers via, for example, a port or drive.
Electronic storage may include one or more of optically readable storage media (e.g., optical disks, etc.), magnetically readable storage media (e.g., magnetic tape, magnetic hard drive, floppy drive, etc.), electrical-charge-based storage media (e.g., EEPROM, RAM, etc.), solid-state storage media (e.g., flash drive, etc.) and/or other electronically readable storage media. Electronic storage may include one or more virtual storage resources (e.g., cloud storage, a virtual private network and/or other virtual storage resources). Electronic storage may store software algorithms, information determined by processors, information received from servers, information received from clients 220 and/or other information that enables the servers to function as described herein.
While an exemplary architecture is described above, it will readily be understood by one of skill in the art that an unlimited number of architectures and computing environments are possible while still remaining within the scope and spirit of the present invention.
Returning now to the specific components of IVSS 100 shown in
Data ingestion module 320 is activated when new data is available from raw databases 200. Following cleansing and normalization of the data, the new data is made available for updating the identity clusters as further described below. As noted above, the data available to IVSS 100 may include various types of data which are used to develop and improve the identity clusters which are, in turn, used when identity verification calls are received, so as to generate scores reflecting the likelihood that the information provided in connection with the call represents a valid identity. The data ingested from raw databases 200 may include, for example, phone number data, physical address data, date-of-birth data, data associated with credit inquiries, utility data and marketing data.
Following ingestion of newly available and cleansed data, as described above, identity cluster creation module 330 updates pending identity clusters 420 to create one or more new identity cluster models, reflecting the updated identity data received from raw databases 200. This updated model is optimized to provide clustering which is incrementally more accurate, in terms of matching against data supplied with identity verification requests as received by IVSS 100. In preferred embodiments of the present invention, model optimization results in more accurate clustering models but also in an enhanced auto-approval rate if possible, as that is desired by customers in order to increase revenue opportunities. More details about the operation of identity cluster creation model 330 as well as the process for generating identity verification models according to the teachings of the present invention are provided below.
Once a new pending identity cluster model is developed, model assessment module 340 then assesses the newly developed model resulting from identity cluster creation 330. In a preferred embodiment this assessment comprises comparing the newly developed pending identity clusters 420 against the currently in-use active identity clusters model 410 to determine whether the pending identity clusters model 420 is statistically significantly improved over the current active identity clusters model 410. This preferably includes, in at least one embodiment, an enhanced rate of auto approvals compared to the existing model.
Assuming that the pending identity cluster model 420 is incrementally better in terms of auto-approval rates, for example, then model management module 350 operates to substitute the pending identity cluster model 420 for the current identity cluster model 410, after which model management module 350 will initiate one or more new pending identity cluster models 420 associated with the new active model 410 so that additional data can be employed to continually update and optimize the relevant model as new data is received over time. Model management module 350 may also function to alert the relevant client(s) 220 concerning a newly rolled-out active model 410 as well as provide any information and/or documentation which is required or useful in connection with client's use of the updated model. In some embodiments, this information may also include new or different information regarding the type and/or format of data which is required and/or desired in connection with client's use of the new model.
Also shown in
With reference now to
In preferred embodiments, the data returned by IVSS 100 to client 220 also includes a series of identity verification scores indicative of the likelihood that each of the data fields supplied by the calling system represents incorrect data. In some embodiments, the scores for each field (identity verification scores) are either 0.99, representing a likely match, or 0.01, representing a likely mismatch. In some embodiments, the returned data may also include one or more reason codes which reflect the justification for the identity scores as well as providing other information associated with various risk factors. For example, the reason codes shown in
In most cases and in preferred embodiments of the present invention, the calling system uses the information returned to it to make an identity verification decision. In some cases, an auto approval may be generated. In other cases, the data set returned may cause the calling system to notify personnel that a manual review may be required (for example, if there are values of 0.01 for one or more identity verification scores or if specific reason codes are returned).
Turning now to
This process encompasses what is also referred to herein as “identity synthesis”, and once identity synthesis is complete a new pending identity cluster model 420 is available. According to the teachings of the present invention, additional steps, as described herein, are also undertaken to determine whether the newly created identity cluster model 420 performs better than the current active identity cluster model 410 such that the current active identity cluster model 410 should be replaced with the newly created identity cluster model 420.
The discussion that follows is an exemplary process for ingesting new data received from raw databases 300, or from some other source, to optimize a cluster model which is later used when an identity verification request is received. In this discussion it is assumed that a single new data file is received from a source associated with raw databases 300 and, further, that the new data is used to update a single pending identity cluster model 420 which may potentially replace one or more active identity cluster models 410. As will be understood by one of skill in the art, the scope and spirit of the present invention is not necessarily limited thereto. For example, and as referenced above, more than one data set may be received at one time and these multiple data sets may be applied to optimize one or more cluster models.
With reference now to
As can be seen in
The next step in the process of identity synthesis, step 730, is record pairing. At this point, identity verification engine 300 and, in particular, identity cluster creation module 330, function to cluster the records into possibly overlapping blocks. These blocks are automatically generated by identity cluster creation module 330. With reference now to
Once a block is defined (e.g. by a concatenation of tokens from different record IDs such as the first three letters of the surname concatenated with the year of birth), system 100 constructs record pairs by taking all 2-combinations of records within each block. This is illustrated in the table at the right in
The processing next proceeds to a record matching step 740. This step is discussed in connection with the tables included in
Entity matching step 740 continues by taking the data generated in the top table of
Record clustering step 750 performs record clustering as will now be described in connection with
The next and final step of the identity synthesis process is identity synthesis step 760. Consistent with the name of this step, the resulting output is a plurality of identity clusters that can be used later for identity verification processing when requests for the same are received by IVSS 100. An example of one identity cluster which is generated upon completion of identity synthesis step 760 is shown in
Next, at step 770 (active cluster model determination), and now that a new 1s pending identity cluster model 420 has been created, the expected performance of this cluster model is measured against the known and expected performance of the active model 410. This function is performed by model assessment module 340 by running identity verification queries on known data, using both models and checking outcomes reflected as percentages of matches achieved with both the active and the pending models. With reference to
If it is determined that performance of the pending model 420 is not statistically significantly better than the performance of the active model 410, then no change in active model is made. Rather, IVSS 100 continues to receive more data from raw databases 300 and the model is continually updated over time until such time as the performance of the development pending model 420 is statistically significantly better than the performance of the active model 410.
Once this happens, IVSS 100, under the control of model management module 350, will substitute the new pending model as the new active model. This step may also include automatically notifying one or more customers via clients 220 of the update to the model as well as providing any information that customers should know about the new model and/or updates to the required format for providing feedback data.
While particular embodiments of the present invention have been shown and described, it will be obvious to those skilled in the art that, based upon the teachings herein, changes and modifications may be made without departing from this invention and its broader aspects. Therefore, the appended claims are to encompass within their scope all such changes and modifications as are within the true spirit and scope of this invention. Furthermore, it is to be understood that the invention is solely defined by the appended claims.
| Number | Name | Date | Kind |
|---|---|---|---|
| 7686214 | Shao | Mar 2010 | B1 |
| 9686275 | Chari | Jun 2017 | B2 |
| 10257181 | Sherif | Apr 2019 | B1 |
| 10581851 | File | Mar 2020 | B1 |
| 20100049987 | Ettorre | Feb 2010 | A1 |
| 20100293094 | Kolkowitz | Nov 2010 | A1 |
| 20110035788 | White | Feb 2011 | A1 |
| 20110047040 | Carlson | Feb 2011 | A1 |
| 20110211735 | Langley | Sep 2011 | A1 |
| 20170032277 | Klinger | Feb 2017 | A1 |
| 20180316665 | Caldera | Nov 2018 | A1 |
| 20190042887 | Nguyen | Feb 2019 | A1 |
| 20190342276 | Sherif | Nov 2019 | A1 |
