Patent Application
20160086263
Account balance and other information for accounts held by an account owner are often needed by third parties for various reasons. For example, when applying for a mortgage, an applicant is typically required to provide information on all of the applicant's accounts to ensure there is sufficient cash attributable to the applicant (e.g., to use as a down payment). As another example, when applying for government benefits, such as supplemental security income (SSI) or other cash or services programs, a beneficiary's accounts must be located to ensure available assets have not been illegally transferred or do not otherwise exceed any qualification amount limits.
Similarly, third parties also often need to verify income. For example, a person applying for mortgage, consumer loan, credit card or other extension of credit may need to have a certain level of income to qualify (or to increase a credit line), and income stated by an applicant when applying for a loan or a credit line usually needs to be verified. Likewise, a person receiving government benefits may also need to have income (or lack of income) verified.
Searching for and verifying account balances and verifying income can be difficult and time consuming. For example, in the case of a mortgage application, where an applicant has a number of accounts at different banks or other institutions (as used herein, “institutions” may include any type of financial service organizations, such as banks, credit unions, third-party payment services such as PayPal or the like, online banking services, online virtual money account systems, investment firms, brokerages, credit card companies, loan companies, check cashing services, payday loan services, government institutions, or any other entity providing financial services or information), verifying account balances may involve sending written requests to a number of different institutions, and each institution conducting a manual look-up for each specified account. Further, the applicant may not have complete account numbers or may not remember or provide information on all accounts. Even if the applicant has account numbers, the applicant may not provide the correct bank name or ID (such as a routing and transit number) to enable convenient and timely verification. In other cases, when the applicant has all the necessary account information, and even if a current balance has been confirmed by a bank, that balance may not be legitimate. That is, an applicant may have received or borrowed funds from another person (such as a relative) to temporarily show an account balance larger than what is actually owned by the account holder, to fraudulently qualify for a mortgage or loan. Also, an loan/credit applicant may represent a certain level of income to qualify, but verifying income may require individually contacting (via phone or letter) one or more employers, and information received back from employers may not be timely or accurate.
In the case of an application for government benefits, an applicant may not disclose accounts (such as accounts where paychecks are deposited), or income reflected in those accounts that would result in disqualification under the benefits program, or may have made transfers out of accounts to conceal assets.
Further, government and law enforcement agencies may from time to time have need to execute and serve subpoenas or National Security Letters (“NSLs”) pursuant to 18 U.S.C. §2709 (or other applicable statutes) to institutions to gain access to financial accounts or information for individuals or entities (such as corporations) named in such subpoenas. However, it is time consuming and expensive for such government and law enforcement agencies to locate institutions that may have information regarding an individual or entity named in a subpoena, and the institutions waste significant resources and expense responding to such subpoenas especially when there is no account or financial information for the named individual or entity that is accessible by the particular institution. The problem is magnified by the current approach of law enforcement to take a “shotgun” approach by delivering subpoenas or NSLs to a large number of major institutions in an attempt to find any applicable accounts for a person or entity of investigatory interest.
Thus, there is a need for systems and methods to locate, verify and/or access account information, especially for accounts that are maintained across a number of different institutions.
Embodiments of the present invention provide systems and methods for locating and accessing assets, such as accounts. For purposes of the present disclosure, accounts may include, but are not limited to, deposit accounts such as checking, savings, CDs, money market accounts in the United States, or International accounts. Accounts may also include (i) reward or loyalty accounts providing merchant reward points, such as in the exemplary case of retail sales; (ii) online financial accounts such as PayPal accounts; (iii) online gaming such as Farmville or SecondLife; or (iv) frequent flyer programs or stored value accounts. Further, accounts may include credit or loan accounts, credit card accounts, debit accounts, prepaid accounts, or any account regarding any desired type of financial information.
In one embodiment, a system and method is provided for locating an account. The system and method provides a database for storing account data for accounts maintained at a plurality of institutions. The account data for each account includes at least a personal identifier for an account holder. A request to locate an account is received, with the request including a submitted personal identifier. The account is located by matching the submitted personal identifier to the personal identifier stored in the database, and at least some of the account data for the located account is retrieved.
In another embodiment, a system and method is provided for locating and accessing an account of an account holder without having to contact one or more institutions where the account might be maintained. The system and method provides a database populated with account data for a plurality of accounts from a plurality of institutions maintaining the accounts. Account data is initially transferred from each of the institutions. The account data represents a plurality of account characteristics associated with each of the accounts. The account characteristics comprise an account identifier assigned to each account by the maintaining institution, a personal identifier for the account holder that is assigned by an entity independently of the institutions, and a balance of funds in the account. Updated account data is also periodically transferred from each of the institutions. The account data is stored in the database. A personal identifier (such as a social security number) for an account holder may be used to locate and retrieve at least some of the account data.
In yet another embodiment, once an account has been located and account data (such as transaction information) accessed, income of the account owner can be identified or verified based on analysis of transactions (that reflect periodic income deposited into the account). In related embodiments, two databases are provided, with a first database storing account ownership data (identifying information for each of the accounts and account holders) and a second database storing transaction data, such as ACH transaction data, posted to the accounts. A personal identifier is provided in order to retrieve from the first database an account identifier associated with personal identifier. The retrieved account identifier is then used to retrieve from the second database ACH transaction data posted to the account, which can in turn be evaluated to identify income reflected in deposits/credits posted to the account.
In still yet another embodiment, a government or law enforcement agency may provide one or more personal identifier(s) corresponding to an individual or an entity named in a subpoena (or an instrument such as a National Security Letter or Writ of Execution) for financial or accounting records access, and the provided personal identifier(s) is/are used to determine which institutions, if any, have account or financial information for the individual or an entity named in the subpoena. If one or more of such institutions are found to have such account or financial information for the individual or an entity named in the subpoena, the names of the matching institutions are provided to the government or law enforcement agency with sufficient information (account number or identification information, for example) so that the subpoena may be efficiently served on the one or more matching institutions. If no matching institutions are found, indicia showing no match found may be returned to the government or law enforcement agency. Although a described embodiment provides the account identification information for subpoenas to government or law enforcement agencies, it is understood by those of skill in the art that a service could be provided to non-government entities or persons to locate bank accounts corresponding to the identified parties. As described more completely below, additional embodiments may perform analysis to provide additional information to the querying entity.
Described embodiments of the present invention provide means for enabling assets (such as financial accounts owned by an account holder) to be located and accessed, even when maintained at a number of different institutions. In some embodiments, accounts are located using a personal identifier associated with the account holder, rather than an account number. In one specific embodiment, the personal identifier is a social security number (SSN).
In certain described embodiments, a system for locating assets may receive different types of requests to locate assets (such as financial accounts). One such request may be an asset search request. Another request may be an asset verification request. A third request may be an income verification request, based on locating accounts that may reflect income (e.g., certain kinds of deposits) made to the located account.
Briefly, as examples, an asset search request might be used by a government entity to locate accounts of a person applying for welfare benefits or some other form of government assistance. Government programs providing benefits (particularly welfare benefits) often have criteria that permit applicants/beneficiaries to qualify only as long as their assets (such as checking, savings and other financial accounts) have balances below a specified threshold. As an example, in many states, a beneficiary must have no more than $2000 in assets in order to qualify for Medicaid nursing home benefits. The systems and methods described herein permit an asset search for any accounts held by the beneficiary in order to confirm that balances in accounts held by the beneficiary are in fact below the required threshold. In other embodiments, transaction data in an identified account may be evaluated to determine or verify benefits eligibility. For example, where benefits eligibility is based on or related to income, a system and method could additionally provide account data relevant to the risk that a beneficiary is receiving income (e.g., deposited into an account) that would make the beneficiary ineligible for benefits. As a more specific example, in the case of unemployment insurance benefits paid by a government agency, transaction data in an identified account could be evaluated to provide risk scores and/or indicators pertaining to whether there might be employment income deposited to an account that would make the account holder ineligible for receiving or continuing to receive unemployment benefits. Data reflecting the likelihood of employment income could be based on data provided for ACH transactions posted to the account (e.g., ACH data indicating payroll deposits), or for non-ACH deposits (e.g., check deposits), based on the payor name or account, the check amount, or other check deposit information (e.g., by comparing that information to prior employment data provided by the beneficiary or by comparing that information to transaction patterns or history). In some embodiments, the periodicity or timing of deposit transactions might be relevant and could be evaluated.
As yet another example, transaction data at located accounts could be used to verify income that has been claimed or stated by a person, such an applicant for a loan (e.g., a mortgage loan). As described above, deposits/credits in the form of ACH transactions (and, in some cases, non-ACH credits/deposits) may be identified that reflect possible or likely income. Such income is reported back to an requester (e.g., a bank where the applicant submitted a loan application). The reported income could be evaluated by the requester for consistency with income stated by the loan applicant. In some embodiments, scores relating to the reported income may also be provided to the requester. For example, one score may provide a likelihood that the deposit/credits reflects actual income. Another score may provide a likelihood of such income occurring in the future (based on the nature or patterns of the identified deposits/credits. Yet another score may reflect a risk associated with located accounts (e.g., a risk of fraud), based on suspicious transactions at the account or other circumstances or personal data associated with the account or the account holder.
An asset verification request, on the other hand, might be used by an entity (such as a mortgage company) to verify account balances. For example, a mortgage applicant may state that the applicant has sufficient funds saved in one or more accounts to make a down payment (or sufficient funds saved to supplement income as needed to make mortgage payments). In this example, a mortgage company needs to verify that balances in the applicant's accounts are adequate to meet the applicant's financial needs after the mortgage has been granted.
Embodiments of the present invention support alternative asset/income search and verification queries or requests. For example, systems and methods as described herein may be used in various situations where account information (such as balances or deposits reflecting income) may be needed, such as to qualify or comply with certain government programs, to obtain consumer/commercial loans, or to initiate legal or other actions. These situations include (but are not limited to) programs involving cash or noncash welfare payments, health care assistance, Supplemental Nutrition Assistance Program (SNAP), Supplemental Security Income (SSI), child support requests (e.g., confirming financial means or needs), Housing Subsidies, Earned Income Tax Credits (EITC), corporate audit verifications, small business loans, student loans, mortgage loans, credit card applications, student financial assistance, credit checks, and delinquent tax collections.
Other embodiments may support asset/income search and verification requests for various kinds of accounts or account information beyond those maintained at financial institutions. For example, government agencies may contribute benefits data, including details relating to those benefits and relating to the beneficiary, such as name, address, social security number (SSN), date of birth, employer (if any), date benefits applied for, type or amount of benefits, date benefits began, agency or agency location, and so forth. As should be appreciated, such information (particularly when accessible by using a personal identifier or SSN of the beneficiary), can be used, e.g., to identify and assess the risk of fraud when processing a beneficiary's request for benefits.
In addition, systems and methods of the present invention permit account information from a large number of banking and other institutions as well as from government agencies to be stored in a single database system (that may include multiple databases) so that accounts across all of those institutions or agencies may be searched or verified with one request. Not only does this eliminate the need for contacting multiple institutions and agencies, but it also permits the data from individual accounts (or multiple accounts) to be analyzed for risk-related factors (e.g., in the case of mortgage applications, factors indicating savings patterns, suspicious deposits, deposits reflecting possible income, and possible links to known fraudsters/con artists; and in the case of government benefits, factors indicating suspicious transfers to third parties or benefits received across multiple jurisdictions or agencies). In some embodiments, search or verification requests may be batched and sent daily. In other embodiments, an individual search or verification request can be sent electronically (on-line and in real-time), and an immediate response can be returned by the system. In one implementation, the located account information sent in the response can be immediately reviewed, perhaps in the presence of the applicant (e.g., while a mortgage applicant is in the presence of a mortgage officer), thus permitting the applicant to explain discrepancies and provide further information that can be used to refine subsequent requests, if appropriate. Such an exchange of information in real time may significantly reduce the time and cost of mortgage qualification, cash and services benefits applications and other processes requiring a search or verification of accounts.
Turning now to
The financial institutions 140 maintain financial accounts, and include banks, savings and loan associations, investment firms and similar institutions. The accounts for which data is provided may include checking accounts, savings accounts, certificates of deposit, brokerage accounts, money market accounts, and other financial accounts (in the United States or elsewhere). Accounts may also include (i) reward or loyalty accounts providing merchant reward points, such as in the exemplary case of retail sales; (ii) online financial accounts; (iii) online gaming accounts; or (iv) frequent flyer programs or stored value accounts. Further, accounts may include credit or loan accounts, credit card accounts, debit accounts, prepaid accounts, or any account regarding any desired type of financial information.
It should be appreciated that, while the embodiment illustrated in
Routing and Transit Number (RTN)
Account Number
Account Type (e.g., checking , savings, certificate of deposit, investment account)
Social Security Number (SSN)/Tax ID Number
Account Status (open/present, closed, deceased, non-sufficient funds, etc.)
Name of Account Holder(s)
Authorized Signor(s) of Account
Address(es) of Account Holder (e.g. a physical mailing address)
Email Address(es) of Account Holder
Phone Number
Date of Birth (DOB) of Account holder
Data date (date of receipt by system 110)
Current Balance
Average Balance (e.g., average balance over the past 30 days)
Interest Paid
Maturity Date (e.g., maturity date for a certificate of deposit)
As should be appreciated,
As seen in
Also,
It should be appreciated that, since the data stored in database system 110 is likely to be extensive for any given account, the account data could be processed in a number of ways by system 110, in addition to being available to a requester making an account search or verification request. For example, the data could be processed to provide balance information in various forms (e.g., a single, current 30 day average balance, or average balances over 6 months, over 1 year or longer). The needs of the requester can thus be met by processing data in a way that is useful to the requester (e.g., a governmental entity is likely to need different information than a mortgage company). In a response the data associated with any account can be filtered, processed and stored in a way to provide only the information on the account that is most useful to the requester.
In addition, and as will be described in more detailed later, the data associated with an account can be analyzed (and, in some cases, compared to data from other, external sources) to provide risk scores or other risk/probability data pertinent to the request. For example, the database system 110 may respond to a mortgage company request with not only basic account information (current status, current account balance, and average balance), but also with alerts and flags if critical data has recently changed (new signers, new account holder names, significant changes in balances, etc.). Also, patterns for deposits and withdrawals (e.g., as reflected in daily balances, or by individual transactions) can indicate if the account holder is a consistently good saver, or has relied on a single or a few large deposits in order to reach the current balance. Transaction data stored in accordance with some embodiments can also be evaluated for indicating possible income to the account holder. If the entity managing the database system 110 provides risk-related data, then data stored in the database could also include a risk marker 216 (stored in a “Risk Flag” field as seen in
While
As mentioned earlier, in some embodiments transaction data for individual accounts may be stored and evaluated at the database system 110 (in addition to the data illustrated
In one embodiment, as briefly described earlier, account information (such as the data illustrated in
The name of the payor can be useful by comparing it to a list of likely employers. Also, among possible SEC codes is “PPD,” which designates a “Prearranged Payment and Deposit Entry.” Such a code is typically used for a recurring entry for a direct deposit of payroll (or recurring payments out of the account for bills), and can thus be used for identifying a recurring transaction. The “Company Entry Description” is text entered by the originator, and it is common for employers to use certain key words such as “payroll” in such text when the transaction is an electronic deposit of a paycheck. As should be appreciated, the review of these fields (individually or together) for a specific transaction will often indicate the type of income attributable to the transaction (payroll/employment, private pension, public pension/benefit (e.g., from social security), investment income (e.g., from an investment company/brokerage), which may be useful for and reported to the requester).
However, as also mentioned earlier, transactions other than ACH transactions may yield useful data in evaluating whether an account holder is receiving income. For example, data associated with the deposit of checks may include the name of the payor, the amount of the check, and the account from which it is drawn (e.g., for comparison to lists of accounts known to be used or likely to be used for payroll).
As also mentioned earlier, account history can establish patterns of transactions and deposits, and can yield data for use in evaluating recent transactions. One strong indicator of employment income is a recurring deposit, since employment income is typically periodic. The amount of net pay will often not change much or at all between pay periods, and if it does change, the change can be attributable to predictable factors, such as annual raises, changes in federal and local tax rates, changes in standard exemptions due to family/personal circumstances, predictable changes in deductions attributable to healthcare and other insurance premiums, sales incentives varying by demand or time of year, and so forth. Also, account history can be used to assess fraud risk in addition to the probability that deposits represent actual income. For example, transactions over a period of time (and posted to multiple accounts) can evidence attempts to conceal assets (holding money in accounts not identified to the agency by the claimant), and transaction patterns of larger amounts being broken into smaller transaction amounts (over multiple accounts) can evidence money laundering. All these patterns and characteristics can be used in assessing the risk of fraud.
In addition, in a specific embodiment involving a person applying for unemployment benefits, the person may be asked to disclose (as part of the application for benefits) sources of income or deposits not attributable to employment income, and that would not disqualify that person from receiving benefits. Examples might be regular non-employment income received from savings, investments and annuities, paychecks received by other family members that might be deposited to an account jointly owned with the claimant, and expense reimbursement amounts or severance pay expected from a past employer (e.g., that might be deposited after termination). All this information can be taken into account in evaluating transactions to determine whether an individual transaction is likely to reflect relevant employment income. In other embodiments, any income (whether from employment or other sources) would be relevant and considered in identifying/verifying income.
Account history and recurring payments can be evaluated in a number of different ways. As an example, an account holder's occupation might result in paychecks of varying amounts (e.g., because the pay was wholly or partly based on commissions). Rather than relying on indicators of near constant income, account history could be considered to determine the timing or frequency of past deposits. If the account holder's account continues to show deposits of the same frequency or on or near the same days of the month as in the past for paychecks (even though varying in amount), such deposits might reflect continuing employment income.
In one embodiment, the data resulting from the analysis of transactions in any account is provided to a scoring model (e.g., implemented by programming within database system 110) which uses statistical or other analysis to determine the likelihood that a deposit reflects income. The scoring model could use a plurality of weighting/risk factors. The actual weighting factors may differ based on fine-tuning and honing of the scoring model, and might change over time based on experience. Different requesters/inquirers may assign different weights to different factors, and in some cases the inquirer using the risk data will choose different weights depending on its own experiences or its risk tolerance. Data is collected and then statistically reviewed to identify specific transactions or patterns of transactions which predict income probability. For example, the design of the model could be based on analysis of large numbers of past transactions (involving many account holders), and the characteristics of such transactions. Based on that empirical and experiential data, predictive data can be generated as to how any given past ACH transactions (or traditional paper check transactions) and their patterns might predict the nature of future similar deposit transactions, including predicting the likelihood that such transactions (and the income that they reflect) will continue for at least some period of time into the future. This may be particularly useful when an income verification is requested in response to an application for a loan or credit, where the loan or credit may extend well into the future. The predictive characteristics are identified and then built into a model. In alternative embodiments of the present invention, neural models or rules models may be used instead of statistical models.
The scoring model might yield a score indicating risk or likelihood of relevant income (for example, from 1-100, with “1” indicating a very low likelihood that a deposits reflects periodic income, and “100” indicating a very high likelihood that there is periodic income). As mentioned earlier, in a response to a query, the score could be accompanied by factors or the circumstances that gave rise to the score, such as continued recurring payments, payments from a known employer, and payments from another source that is likely to pay income. Such information is provided to the inquirer with the level of detail that may be needed to investigate and determine whether the income is relevant or not to the inquirer. For example, the score could accompany details for specific transactions (including amounts) that reflect possible income and that gave rise to the score.
A specific scoring model that could be used in certain embodiments will be described later in conjunction with
Turning now to
If accounts are identified with the provided personal identifier, the system looks for matches with other data (if any) provided by the requester (step 420). For example, a name or address provided in the request is compared to the data stored in system 110 for the identified account, and if there is no match the requester is notified and the search may end (at least temporarily). Alternatively, the process could continue, but with the understanding that the account data may not be relevant to the person that is the subject of the request. If the data matches at step 420, then the data for the identified account is retrieved, step 422. If risk data is also to be provided (if available and requested, step 424), then the risk data is retrieved (step 426) and the retrieved data is provided to the requester as part of the response (step 430).
As mentioned above, in some cases, even if an account is not identified with a personal identifier such as an SSN (step 414), the system 110 can be programmed to locate accounts using other personal information of the person in question. This is illustrated in
The system notifies the requester as to the nature of the matches (step 620). If there is no match of any accounts (no match of either the personal identifier or the account number), the requester is so notified and the process may end with that notification at step 620 (as indicated in
If risk data is also to be provided (if available and requested, step 624), then the risk data is retrieved (step 626) and the retrieved data is provided to the requester as part of the response (step 630).
While
In some embodiments risk-related data (e.g., a risk score) may be generated based on the account data provided to and stored database system 110, and provided to a requester as described in conjunction with
The process of
In
The following tables illustrate scoring analysis (exemplary risk factors and corresponding risk impact) that could be used in scoring logic 710, for both an account search request (involving government benefits) and an asset verification request (involving a mortgage application). In one embodiment, the risk scores could be calculated by initially assigning a neutral score (e.g., 50), and then increasing or decreasing the initial score based on the risk impact identified in the tables. Also, individual risk factors could be weighted differently, e.g., depending on desires of the requester or based on experiential data collected by the operator of the system 110. Further, some risk factors require comparing account data to relevant data in separate, external databases (as an example, such databases might store names, addresses, email addresses, phone numbers and account numbers of suspected fraudsters). The system 110 would access those external databases as necessary in performing various risk analysis steps.
Also, because the system 110 will likely store account information across most (if not all) financial institutions, additional data (not directly related to the account at hand) can be collected to provide additional forms of risk analysis. For example, if account data for an account is accessed and it reveals a large deposit (or a series of recent deposits that total a large amount), all other accounts in the system could be checked to see if a corresponding and identical withdrawal amount (or series of withdrawals) can be matched, thus linking another account (as a source account) to the account at hand. The system 110 could then check external databases to see if the source account is associated with a fraudster.
Embodiments of the invention also support other useful ways to tap the extensive and rich source of information maintained in the system 110. For example, the account data (including the risk scores) maintained in the system 110 may be used to assess creditworthiness. Not only could stored risk data be used in such an assessment, but loan or other credit accounts could be accessed (e.g., using only a SSN) to locate outstanding balances or credit limits (when stored in association with such accounts), and thus determine either the general creditworthiness of a person or entity (e.g., a person applying additional credit), but also verify representations made by an applicant in connection with the applicant's existing accounts.
In some embodiments of the invention, account data located at the database system 110 may be used to identify or verify income for an account holder. A process implemented at database system 110 for such purpose is illustrated in
The process begins with a query from a requesting entity. In one embodiment, the requesting party could be a government agency that administers unemployment income benefits, wanting to verify that an applicant has no employment income. In another embodiment, the requesting party could be a mortgage company or other entity wanting to verify income provided by an applicant (e.g., to confirm income stated on a mortgage loan application). These are only two examples and there are, of course, many other possible situations where a requesting party may want to identify or verify income. The query could either be as part of the initial screening of an applicant (block 810) or as part of on-going periodic monitoring of accounts for changes in income (block 812). An example of ongoing monitoring would be a mortgage company wanting to monitor accounts of an applicant to determine when income has changed (e.g., an applicant has become unemployed or has had a reduction in pay). In both cases, the overall process for verifying income may involve the same or similar steps following the query steps 810, 812. In each case, the query received from the requesting entity would include personal data identifying the applicant.
For example, in an initial applicant screening at step 810, the requester could send the applicant's name, address, social security number, and one or more account numbers, e.g., account numbers provided by the applicant (either alone or jointly with others). The initial query could be real-time or near-real-time, with data entered by the requester and a real-time response returned indicating (as will be described) whether there is income likely received at the located accounts (and perhaps a score indicating the degree of likelihood that a deposit is in fact income). Alternatively, the query could be made in batch-mode, say at the end of each day, reflecting all loan applications received that day, with results returned for all those applications.
In the case of on-going verification at step 812, the requester could send personal data concerning one or more applicants. In one embodiment, queries at step 812 would be sent at regular intervals in batch mode with files for a group of some or all current applicants, updated to reflect any changes to information for individual applicants (such as new account numbers) and also including new applicants that have been added since the last query and deleting applicants whose loans have been approved/denied since the last query. Alternatively, the query at step 812 could be in real-time for a single, current applicant whose loan application is pending.
Using the personal data or information in the query, accounts are located at step 814. Accounts may be located by account numbers given in the query. Alternatively, the claimant's social security number, name, or address could be used to also locate accounts that might be present in database 120, in a manner similar to that described in conjunction with
If no accounts are located, the requester is notified at step 818. In the case of an initial screening, such a circumstance might require follow-up with the applicant to make sure correct account information was given. In some embodiments, the absence of a located account might be used to indicate risk associated with the application (e.g., a perceived higher risk if the applicant appears to have provided false information). Similarly, if an applicant gives an account number and other personal information (name, social security number, etc.) found in database system 110 and the located account does not match the applicant, a risk score assigned to that applicant might also be increased. In some embodiments, if step 814 identifies a large number of accounts owned by the applicant, such fact in and of itself might be a factor that would increase risk (fraudsters often set up and access many accounts in order to conceal fraudulent activity).
If accounts are located at step 814, then account data for those accounts are retrieved from database system 110, step 820, for subsequent analysis.
In one embodiment as described earlier, the database system 110 consists of two separate databases rather than the illustrated single account database 120 (
The use of two databases within database system 110 as just described provides advantages in efficiency and operation of the system 110 when performing an income identification/verification process, such as that illustrated in
At step 822, parameters are established/retreived for review of account data, such as the transaction data retrieved at step 820. The parameters could depend on the nature of the query (e.g., initial screening vs. on-going verification). The parameters could also depend on the desires of the requester. For example, in the case of an initial screening, the time window might be established for transactions within six month period prior to a loan application. In the case of on-going verification, the time window for which the transactions are to be reviewed could be, e.g., the period of time since the date of the loan application.
Transaction data is then evaluated at system 110, step 826. Such evaluation could be done, for example, for ACH and non-ACH transactions as described earlier in conjunction with
The results reflect likely income (amounts, period of time over which likely income was posted, and income type) and would be provided to the requester at step 830, e.g., in the form of an electronically communicated report. In addition, since there may be some ambiguity as to whether deposits/credits reflect actual income, a score reflecting the likelihood that reported income is in fact actual income could also be provided at step 830. Further, a score relating to the predictability of the income continuing for some period of time in to the future (based on the nature of the transactions) could be provided. Finally, if there are any risk factors relating to fraud associated with the applicant's account, that could also be provided in the report at step 830.
In some embodiments, a requester, such as a bank seeking to verify income for a loan applicant), may want to reduce the transmission of personal identifiers between itself and the system 110. This can be accomplished, for example, by the requester providing a request reference number along with a personal identifier (step 810 or step 812). When a response is received, such as the requester being notified that no accounts have been located (step 818) or a report of income and probability/risk scores (step 830), the response provides the request reference number along with reported results, but without returning personal identifiers originally provided by the requester.
In one alternative embodiment, the query at step 810 may be from an agency at which the applicant has applied (or made a claim) for unemployment insurance (UI) benefits, and that agency is making a request to determine the likelihood of employment income (in the form of deposit/credits) posted to an account and that would disqualify the applicant/claimant from receiving such benefits. The following Table I illustrates for such embodiment a simplified and high-level risk score model, with only one of four risk scores (Risk Scores 1-4) given for each claimant, based on six different combinations of various risk criteria/factors (Risk Criteria A-F).
In this embodiment, Risk Score 1 represents the highest risk of there being disqualifying income for a claimant. In this category, the name, social security number (SSN), routing number and account number given in a query are found to match data in the database 120 (Risk Criteria A). The Type of Account (in which a relevant transaction with risk has been found) is an individual account (Risk Category B). Risk Criteria C or E also are found, i.e., either a UI deposit and payroll deposit are found in the same period in the same account (Risk Criteria C), or the payroll (employment) deposit is found in the same period in a different account (not the account where the UI deposit is made) that is owned by the claimant (Risk Criteria E).
Risk Score 2 is a lower risk than Risk Score 1, and in this category the name, social security number (SSN), routing number and account number are found to match data in the database (Risk Criteria A). The Type of Account is an individual account (Risk Category B). Risk Criteria D or F are also found, i.e., either the UI deposit and a recurring deposit are found in the same period in the same account (Risk Criteria D) or a recurring deposit is found in the same period in a different account owned by the claimant (Risk Criteria F). This risk is lower because a recurring deposit may (or may not) reflect employment income, and thus the likelihood of fraud is deemed lower in the scoring model.
Risk Score 3 is a lower risk than Risk Score 2, and the criteria found are similar to Risk Score 1, except that the type of account located is a joint account co-owned by the claimant, rather than an individual account (or the individual/joint feature is unknown). This risk is lower because a payroll deposit in a joint account may be attributable to the co-owner, and thus the likelihood of fraud is deemed lower.
Risk Score 4 is a lower risk than Risk Score 3, and the criteria found are similar to Risk Score 2, except that the type of account located is a joint account co-owned by the claimant rather than an individual account. This risk is lower because a recurring deposit in a joint account may not be employment income, and the recurring deposit may be attributable to the co-owner, and thus the likelihood of fraud is lower.
As should be understood, the forgoing is only a simple example of a risk score arrangement, and many other scoring models are possible, e.g., models involving more sophisticated analyses, more (or different) risk criteria including any of the applicant's identity information or parameters, and courser or finer granularity of levels of risk scores.
In some embodiments, risk can be analyzed and scored using data other than deposit transactions posted to a claimant account. In some cases, all types of transactions might be reviewed, including those reflecting expenditures or payments out of the account. As an example, transaction payments out of the account to persons or entities associated with fraud or other suspicious activity might increase a risk score. In addition, while the described embodiments primarily discuss the review of transactions posted to checking accounts (or demand deposit accounts “DDA”), many other types of accounts at the institutions 140 can be accessed in evaluating risk, such as savings accounts, debit card accounts, brokerage and investment accounts, stored value accounts, and money transfer accounts, information from payroll processing services, payroll data aggregators, payroll payment providers, military benefits administrators, state or federal governmental taxing authorities such as the Internal Revenue Service, or any other desired data source comprising income-related information . These other types of accounts may be used individually or in combination with each other and/or checking/DDA accounts.
As a further aspect of the present invention, a government or law enforcement agency may provide one or more personal identifier(s) corresponding to an individual or an entity named in a subpoena (or an instrument such as a National Security Letter or Writ of Execution) for financial or accounting records access, and the provided personal identifier(s) is/are used to determine which institutions, if any, have account or financial information for the individual or an entity named in the subpoena. If one or more of such institutions are found to have such account or financial information for the individual or an entity named in the subpoena, the names of the matching institutions are provided to the government or law enforcement agency with sufficient information (account number or identification information, for example) so that the subpoena may be efficiently served on the one or more matching institutions. If no matching institutions are found, indicia showing no match found may be returned to the government or law enforcement agency. As described more completely below, additional embodiments may perform analysis to provide additional information to the querying agency. The personal identifier for the individual or entity named in the subpoena may comprise any desired identification element, including, but not limited to, an SSN, a personal name, a mailing address, a physical address, the name of a corporate entity, a driver's license number, a prisoner number, an immigration number, a Matricula Consular number, or any other desired indicia. Further, personal identifiers may constitute a plurality of information designed to either narrow or broaden the search criteria depending on the desired result. Requiring more than one match for a plurality of provided identifiers might produce fewer results and would narrow the search. A match for any one of a plurality of provided identifiers might produce more results and would broaden the search.
For example, furnishing a plurality of personal identifiers such as an SSN and name and address (and requiring that an identified account have a match for each of the SSN, name and address) may further refine the search results and limit false positives, but depending on the amount of information returned, submissions of multiple identifiers, if a multiple match is required, could return too little information to be useful. Optionally, and to further refine results, the submitting agency may specify which of the submitted personal identifiers are required, and which may be optional, or which may be required in combination. For example, the submitting agency may specify that both a last name and an SSN must match the submission. In some embodiments, personal identifiers may comprise a list of related information for a suspect individual, for instance, a list of personal identifiers corresponding to known associates of the individual, and accounts of the known associates may be identified (along with the accounts of the suspect individual). Using additional analysis techniques, which may include link analysis or network analysis, account information corresponding to known associates and to others linked to the individual or entity identified in the subpoena may be returned to the submitting agency.
A simplified illustration of one such process is seen in
As a specific example addressing an embodiment of the present invention, consider a hypothetical subpoena that is planned to be issued so that a law enforcement agency may find and obtain financial account information (and possibly related information) for an individual named Vito A. Corleone who has an SSN of 123-45-6789. Prior to embodiments of the present invention being available, difficulties immediately arise in trying to determine which financial institutions may have accounts for Vito Corleone; prior practices may have involved serving subpoenas or NSLs on a large number of financial institutions hoping that one or more of them have an account for Vito Corleone. In the process, much time and expense was wasted serving the subpoenas or NSLs to the institutions not having accounts for Vito, as well as the wasted time and expense borne by the financial accounts in responding to such “blind guess” subpoenas. However, in embodiments of the present invention, the law enforcement agencies may be provided indicia regarding which institutions have accounts related to Vito Corleone with a matching SSN, and optionally, account identifying information corresponding to accounts for which Vito is a signatory.
In a modification of the previous example, consider the case where no hits were found for Vito Corleone, with or without his SSN, at any institution's records stored in the database system 110 of the present invention. It may be likely that accounts may have been opened at various institutions by Vito's known associates to attempt to conceal Vito's financial transaction information. In an embodiment of the present invention, Vito's last known address was known by the submitting law enforcement agency (123 Genco Way, Long Island N.Y.), and a list of known associates: P. Clemenza, S. Tessio, L. Brasi, D. Tommasino, and T. Hagen. A query could then be submitted to systems of the present invention to find accounts matching his address and any of his known associates, and such accounts may then be scrutinized to determine whether they are associated with Vito Corleone. Those of skill in the relevant arts also realize that other cross-matching information (for example Vito's middle name “Andolini”) might be utilized with or without his SSN, and with or without other identifying information such as known associates. Further, through analyzing a network of Vito's associations created through linking and network analysis techniques as more completely described in U.S. Provisional Patent Application No. 61/448,156 filed Mar. 1, 2011 entitled, “System and Method for Suspect Entity Detection and Mitigation,” the disclosure of which is hereby fully incorporated by reference for all purposes, ancillary information regarding Vito Corleone's social or financial transaction history may be analyzed to determine possible accounts that have some association with Vito. Types of ancillary information provided about Vito may include checking account records of any kind (bank statements, cancelled checks, etc.), loan information (loan applications, ledgers, etc.), savings account and securities records (certificates of deposit, investments, etc.), records of any safe deposit boxes at a bank, supporting financial documents (copies of tax returns, credit reports, etc.), current or present addresses associated with an account, hot files, accounts closed for cause, mobile or land line phone numbers associated with Vito or his present or prior addresses, and the like. Once a network has been constructed with Vito's identifying information, related accounts (or other information) and the institutions that host them, may be provided to the querying law enforcement agency.
Submissions of requests for subpoena/NSL account identification may be made by the requesting agency individually in a real-time, or in a single or grouped batch mode submittal that is executed at a predetermined time interval (for example, overnight). Additionally, further analysis could produce information that may be provided to the requesting government or law enforcement agency regarding identity information for other individual signatories on joint accounts that correspond to the individual or entity named in the subpoena; prior transactions indicating financial fraud related to the individual or entity named in the subpoena, and through network analysis, identifications of or risk indicia regarding any potential fraud rings associated with the individual or entity that is named in the subpoena. As such, additional related investigatory leads may be provided to the government or law enforcement agency as a result of social or transactional associations with other entities. In an additional aspect, the requesting agency (or an entity, broker, or processor acting on the agency's behalf), after determining which institutions possess information about the subject of the subpoena/NSL, may send to the relevant institutions a formatted request for information that allows the possessing institutions to “fill in the blanks” for any missing data that is pertinent to the subject of the subpoena/NSL, and the requesting entity/broker/processor may process the response on the institution's behalf directly to the law enforcement agency. In a further aspect of the present invention, the requesting government agency may specify to a processor/broker the relevant laws, statutes, rules, or orders under which it has acting authority to submit the subpoena/NSL, and the processor/broker pursues obtaining the information for the agency on its behalf Further, the processor/broker may utilize the specified listing of laws, statutes, rules or orders furnished by the government agency to tailor the information request to one or more institutions that have been determined to possess information about the subject of the subpoena/NSL, and may optionally filter or redact any information that is received from the relevant institutions that is not permitted to be provided under a legal framework of identified statutes, laws, or rules.
The computer system 1000 is shown comprising hardware elements that may be electrically coupled via a bus 1090. The hardware elements may include one or more central processing units 1010, one or more input devices 1020 (e.g., a mouse, a keyboard, etc.), and one or more output devices 1030 (e.g., a display device, a printer, etc.). The computer system 1000 may also include one or more storage devices 1040, representing remote, local, fixed, and/or removable storage devices and storage media for temporarily and/or more permanently containing computer-readable information, and one or more storage media reader(s) 1050 for accessing the storage device(s) 1040. By way of example, storage device(s) 1040 may be disk drives, optical storage devices, solid-state storage device such as a random access memory (“RAM”) and/or a read-only memory (“ROM”), which can be programmable, flash-updateable or the like.
The computer system 1000 may additionally include a communications system 1060 (e.g., a modem, a network card—wireless or wired, an infra-red communication device, a Bluetooth™ device, a near field communications (NFC) device, a cellular communication device, etc.) The communications system 1060 may permit data to be exchanged with a network, system, computer, mobile device and/or other component as described earlier. The system 1000 also includes working memory 1080, which may include RAM and ROM devices as described above. In some embodiments, the computer system 1000 may also include a processing acceleration unit 1070, which can include a digital signal processor, a special-purpose processor and/or the like.
The computer system 1000 may also comprise software elements, shown as being located within a working memory 1080, including an operating system 1084 and/or other code 1088. Software code 1088 may be used for implementing functions of various elements of the architecture as described herein. For example, software stored on and/or executed by a computer system, such as system 1000, can be used in implementing the processes seen in
It should be appreciated that alternative embodiments of a computer system 1000 may have numerous variations from that described above. For example, customized hardware might also be used and/or particular elements might be implemented in hardware, software (including portable software, such as applets), or both. Furthermore, there may be connection to other computing devices such as network input/output and data acquisition devices (not shown).
While various methods and processes described herein may be described with respect to particular structural and/or functional components for ease of description, methods of the invention are not limited to any particular structural and/or functional architecture but instead can be implemented on any suitable hardware, firmware, and/or software configuration. Similarly, while various functionalities are ascribed to certain individual system components, unless the context dictates otherwise, this functionality can be distributed or combined among various other system components in accordance with different embodiments of the invention. As one example, the central account database system 110 system may be implemented by a single system having one or more storage device and processing elements. As another example, the central account database system 110 system may be implemented by plural systems, with their respective functions distributed across different systems either in one location or across a plurality of linked locations.
Moreover, while the various flows and processes described herein (e.g., those illustrated in
This application is a continuation-in-part of U.S. application Ser. No. 13/213,975, entitled SYSTEM AND METHOD FOR LOCATING AND ACCESSING ACCOUNT DATA, filed Aug. 19, 2011, which claims the benefit of priority to U.S. Provisional Application No. 61/499, 599, entitled SYSTEMS AND METHODS FOR FRAUD DETECTION/PREVENTION FOR A BENEFITS PROGRAM, filed Jun. 21, 2011, each of which is hereby incorporated by reference in its entirety for all purposes.
| Number | Date | Country | |
|---|---|---|---|
| 61499599 | Jun 2011 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 13213975 | Aug 2011 | US |
| Child | 14959881 | US |
