U.S. patent application number 13/213975 was filed with the patent office on 2012-12-27 for system and method for locating and accessing account data.
This patent application is currently assigned to Early Warning Services, LLC. Invention is credited to Lucius L. Lockwood, Tom McLaughlin, Dawn Melvin, Janis E. Simm, Christopher E. Swecker, Laura Weinflash.
Application Number | 20120330819 13/213975 |
Document ID | / |
Family ID | 47362684 |
Filed Date | 2012-12-27 |
United States Patent
Application |
20120330819 |
Kind Code |
A1 |
Weinflash; Laura ; et
al. |
December 27, 2012 |
SYSTEM AND METHOD FOR LOCATING AND ACCESSING ACCOUNT DATA
Abstract
Account data (e.g., balance information) for accounts at a
plurality of financial institutions (or government agencies) is
stored (and updated) in a central database system and accessed
using a personal identifier, such as a social security number. Risk
data may be generated for accounts based on the account data. The
account data and risk data are accessed in response to either an
account search request (e.g., from a government entity and relating
to a benefits program or a subpoena) or an account verification
request (e.g. from a mortgage company and relating to a mortgage
application).
Inventors: |
Weinflash; Laura;
(Scottsdale, AZ) ; Melvin; Dawn; (Scottsdale,
AZ) ; McLaughlin; Tom; (Phoenix, AZ) ; Simm;
Janis E.; (Scottsdale, AZ) ; Swecker; Christopher
E.; (Charlotte, NC) ; Lockwood; Lucius L.;
(Phoenix, AZ) |
Assignee: |
Early Warning Services, LLC
Scottsdale
AZ
|
Family ID: |
47362684 |
Appl. No.: |
13/213975 |
Filed: |
August 19, 2011 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
61499599 |
Jun 21, 2011 |
|
|
|
Current U.S.
Class: |
705/38 ;
705/35 |
Current CPC
Class: |
G06Q 40/02 20130101 |
Class at
Publication: |
705/38 ;
705/35 |
International
Class: |
G06Q 40/00 20120101
G06Q040/00; G06Q 40/02 20120101 G06Q040/02 |
Claims
1. A computer-implemented method, comprising: providing a database;
storing, in the database, account data for accounts maintained at a
plurality of institutions, the account data for each respective
account comprising at least a personal identifier for an account
holder of that respective account; receiving a request to locate an
account, the request including a submitted personal identifier;
locating an account by matching the submitted personal identifier
to the personal identifier stored in the database for the located
account; and retrieving at least some of the account data for the
located account.
2. The method of claim 1, further comprising: providing a response
to the request to locate an account, the response comprising the
retrieved account data.
3. The method of claim 1, wherein the personal identifier is
assigned by an entity independent of the institution maintaining
the account.
4. The method of claim 1, wherein the personal identifier comprises
a social security number.
5. The method of claim 1, wherein the plurality of accounts are
financial accounts and wherein the database is populated with
account data from financial institutions.
6. The method of claim 1, wherein the account data for each account
further comprises an account balance for such account, and wherein
the step of retrieving at least some of the account data comprises
retrieving the account balance for the located account.
7. The method of claim 6, wherein the account data for each account
further comprises at least one or more of an account type, a name
of the account holder, an identity of designated signers for the
account, an average balance over a predetermined period of time,
interest paid on the account during a predetermined period of time,
a physical address associated with the account holder, an email
address associated with the account holder, a phone number
associated with the account holder, and a date of birth associated
with the account holder.
8. The method of claim 1, wherein the plurality of accounts
comprises benefits accounts relating to benefits provided to the
account holder as a beneficiary under a benefits program, and
wherein at least one of the institutions maintaining the accounts
comprises an entity managing the benefits program.
9. The method of claim 8, wherein the entity managing the benefits
program comprises a governmental agency.
10. The method of claim 8, wherein the account data for each
account further comprises benefits data relating the scope of
benefits being provided to the account holder.
11. The method of claim 8, wherein the benefits comprise cash
payments to the beneficiary.
12. The method of claim 8, wherein the benefits comprise services
provided to the beneficiary.
13. The method of claim 8, wherein the account data for each
account further comprises at least one or more of a beneficiary
name, a beneficiary address, a beneficiary date of birth, a
beneficiary employer, a date benefits were applied for, a benefits
type, a benefits amount, a date benefits began, an identification
of an agency administering the benefits, and a location of the
agency.
14. The method of claim 1, wherein the account data further
comprises, for each account, both initially transferred account
data from each of the institutions and periodically updated account
data from each of the institutions.
15. The method of claim 1, wherein the account data further
comprises risk data associated with one or more of the
accounts.
16. The method of claim 15, further comprising: inputting the
account data for one or more of the accounts to scoring logic;
generating, at the scoring logic, risk data for one or more of the
accounts based on the inputted account data; and storing the risk
data in the database as account data.
17. The method of claim 16, wherein the risk data generated at the
scoring logic comprises a risk score associated with the one or
more of the accounts.
18. The method of claim 16, wherein the risk data generated at the
scoring logic reflects whether the account howler is a consistent
saver, based on a pattern of deposits and withdrawals at the 1 one
or more accounts.
19. The method of claim 16, wherein the risk data generated at the
scoring logic reflects recent transfers of amounts from the one or
more of the accounts.
20. The method of claim 16, wherein the step of generating risk
data comprises comparing account data populating the database for
the one or more of the accounts to data associated with suspected
fraudsters.
21. The method of claim 16, wherein the risk data generated at the
scoring logic reflects whether an authorized signer has changed for
the one or more of the accounts.
22. The method of claim 1, wherein the request to locate an account
is made in response to an application for a loan, wherein an
applicant has represented a balance for an applicant account,
wherein the retrieved account data includes an account balance for
a located account corresponding to the applicant account, and
wherein the method further comprises: verifying that the
represented balance from the applicant is consistent with the
balance for the located account.
23. The method of claim 1, wherein the request to locate an account
is made in response to an application for benefits, wherein the
benefits program requires a specified level of assets available to
the applicant, wherein the step of locating an account comprises:
searching for all accounts in the database having stored account
data with a personal identifier that matches the submitted personal
identifier.
24. The method of claim 23, wherein the retrieved account data
comprises an account balance for any located account, and wherein
the method further comprises: verifying that a total of account
balances for all located accounts meets the required specified
level of assets.
25. The method of claim 1, wherein the plurality of accounts
comprise one or more of a checking account, savings account,
certificate of deposit account, money market account, stored value
account, credit account, loan account, credit card account, debit
account, prepaid account, reward account, loyalty account, online
payment service account, and on-line gaming account.
26. The method of claim 1, wherein the plurality of accounts
comprise loan accounts and the account holder is the obligor for
the loan underlying each loan account, and wherein the account data
further comprises an outstanding balance or a credit limit for such
loan account.
27. The method of claim 1, wherein the account data populating the
database further comprises an account identifier for each of the
accounts, wherein the step for receiving a request to locate an
account further includes a submitted account identifier in the
request.
28. The method of claim 27, further comprising: locating an account
by matching the submitted account identifier to the account
identifier stored in the database for the account.
29. The method of claim 28, wherein the step of retrieving at least
some of the account data comprises both retrieving account data for
any account located using the submitted personal identifier and
retrieving account data for any account located using the submitted
account identifier.
30. The method of claim 28, further comprising: retrieving account
data for any account located using the submitted account identifier
when that same account is not located by matching the submitted
personal identifier to the personal identifier stored in the
database for the account.
31. The method of claim 28, wherein the account identifier
comprises an institution identifier and an account number, and
wherein the method further comprises: transmitting a request to an
institution identified by the institution identifier in the account
identifier, when no account is located in the database using the
submitted account identifier; receiving account data from the
identified institution for the account associated with the
submitted account identifier; and providing a response to the
request to locate an account, the response including the account
data received from the identified institution.
32. The method of claim 1, wherein the step of locating an account
comprises: comparing the submitted personal identifier to the
personal identifier stored in the database for each of the
accounts; and identifying an account as a located account if the
submitted personal identifier matches the personal identifier
stored in the database for the located account.
33. The method of claim 1, further comprising: providing a response
to the request to locate an account when no account located, the
response including notification that no account has located by
matching the submitted personal identifier to the personal
identifier stored in the database.
34. The method of claim 1, wherein the account data for each
account populating the database further comprises personal data for
the account holder, the personal data including at least one or
more of a name of the account holder, a physical address associated
with the account holder, an email address associated with the
account holder, a phone number associated with the account holder,
and a data of birth associated with the account holder, wherein the
request to locate further comprises submitted personal data, and
wherein the method further comprises: providing a response to the
request to locate an account when there is no match between
submitted personal data and the personal data populating the
database for any account that is located, the response including
notification that there is no match of personal data for the
located account.
35. The method of claim 1, wherein the submitted personal
identifier is associated with a subject of a writ issued by a
governmental entity, and wherein the located account is associated
with the subject of the writ.
36. The method of claim 35, wherein the writ is one of a subpoena
and a writ of execution, and a National Security Letter.
37. The method of claim 35, wherein the submitted personal
identifier is related to known associates of the subject of the
writ.
38. The method of claim 35, further comprising locating ancillary
information related to the subject of the writ, by applying linking
analysis to the submitted personal identifier to find associations
between the submitted personal identifier and the ancillary
information.
39. The method of claim 38, wherein the ancillary information
comprises records relating to one or more of open accounts, loans,
securities, safe deposit boxes, financial documents, past and
present addresses, hot files, accounts closed for cause, and past
and present phone numbers.
40. The method of claim 35 further comprising: receiving the writ
from the governmental entity by a processor/broker, determining, by
the processor/broker, at least one institution that possesses
information about a subject of the writ; requesting, from the at
least one financial institution, information identified in the
writ; and returning the information by the processor/broker to the
governmental entity.
41. The method of claim 40 wherein prior to returning the
information to the governmental entity, the processor/broker
filters the information to remove any information not permitted to
be furnished to the governmental entity under a legal
framework.
42. A system, comprising: a database storing data for accounts from
a plurality of institutions, the stored data for each respective
account comprising at least a personal identifier for an account
holder of that respective account; and a processor configured to:
receive a request to locate an account, the request including a
submitted personal identifier; locate an account by matching the
submitted personal identifier to a personal identifier stored in
the database for that account; and retrieve from the database
stored data associated with any located account.
43. The system of claim 42, wherein the processor is further
configured to: provide a response to the request to locate an
account, the response including the retrieved account data when an
account is located using the submitted personal identifier.
44. The system of claim 42, wherein the personal identifier is
assigned by an entity independent of the institution maintaining
the account.
45. The system of claim 42, wherein the personal identifier
comprises a social security number.
46. The system of claim 42, wherein the plurality of accounts are
financial accounts and wherein the database is populated with
account data from financial institutions.
47. The system of claim 42, wherein the plurality of accounts
comprises benefits accounts relating to benefits provided to the
account holder as a beneficiary under a benefits program, and
wherein at least one of the institutions maintaining the accounts
comprises an entity managing the benefits program.
48. The system of claim 47, wherein the entity managing the
benefits program comprises a governmental agency.
49. A computer-implemented method, comprising: providing a
searchable database; populating the database with account data
associated with accounts from a plurality of institutions, each of
the accounts having an account holder identified by a personal
identifier; in response to a request to locate an account,
searching the database using a submitted personal identifier;
locating an account when the submitted personal identifier matches
a personal identifier associated with an account holder of one of
the accounts; and retrieving at least some of the account data
associated with any account that is located.
50. A computer-implemented method, comprising: providing a
database; storing in the database account data for accounts from a
plurality of institutions, wherein each of the respective accounts
is a loan account having an associated account identifier; in
response to a request to locate an account in the database,
searching the database using a submitted account identifier
included with the request; locating an account by matching the
submitted account identifier to the account identifier associated
with one of the accounts; and retrieving at least some of the
account data for any account that is located.
51. The method of claim 50, wherein the retrieved account data
comprises an outstanding account balance for the located
account.
52. The method of claim 51, wherein the retrieved account data
comprises a credit limit for the located account.
53. A computer-implemented method, comprising: providing a database
to be populated with account data for a plurality of accounts from
a plurality of financial institutions maintaining the accounts;
initially receiving, from each of the plurality of financial
institutions and for storing in the database, account data
representing a plurality of account characteristics respectively
associated with each of the plurality of accounts, wherein the
account characteristics for each respective account comprise (a) an
account identifier assigned to that respective account by the
maintaining financial institution, (b) a personal identifier for an
account holder of that respective account, and (c) a balance of
funds in that respective account; periodically receiving updated
account data from each of the financial institutions; storing in
the database the initially received account data and the updated
account data; receiving a submitted personal identifier for an
account holder to locate any accounts at any of the financial
institutions associated with that account holder; and retrieving at
least some of the account data associated with any account that is
located using the submitted personal identifier.
54. The method of claim 53, wherein the personal identifier is
common to accounts of the account holder at more than one financial
institution.
55. The method of claim 54, wherein the personal identifier
comprises a social security number.
56. A computer-implemented method, comprising: providing a database
for being populated with benefits data, the benefits data
associated within benefits provided to beneficiaries under benefit
programs administered by a plurality of governmental agencies;
initially receiving benefits data respectively associated with each
of the beneficiaries, wherein the benefits data for each respective
beneficiary comprises (a) a personal identifier for the respective
beneficiary, and (b) the scope of benefits being provided to the
respective beneficiary under any of the benefits programs;
periodically receiving updated benefits data associated with each
of the respective beneficiaries; storing in the database the
initially received benefits data and the updated benefits data;
receiving a submitted personal identifier to locate any benefits
data stored in the database and associated with one of the
beneficiaries; and retrieving at least some of the located benefits
data.
57. The method of claim 56, wherein the personal identifier is
common to beneficiaries under more than one of the benefits
programs.
58. The method of claim 57, wherein the personal identifier
comprises a social security number.
Description
CROSS-REFERENCES TO RELATED APPLICATIONS
[0001] This patent application claims priority to U.S. Provisional
Patent Application No. 61/499,599 entitled, "Systems and Methods
for Fraud Detection/Prevention for a Benefits Program," filed Jun.
21, 2011, the complete disclosure of which is fully incorporated by
reference herein for all purposes.
BACKGROUND OF THE INVENTION
[0002] 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.
[0003] Searching for and verifying account balances 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 that what is actually owned by the account holder, to
fraudulently qualify for a mortgage, loan, or government
benefit.
[0004] In the case of an application for government benefits, an
applicant may not disclose accounts, 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.
[0005] 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. .sctn.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 which institutions 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.
[0006] 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.
BRIEF SUMMARY OF THE INVENTION
[0007] 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.
[0008] 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.
[0009] 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.
[0010] In an additional aspect, 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 preferred 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
agency.
BRIEF DESCRIPTION OF THE DRAWINGS
[0011] FIG. 1 is a block diagram of a system for locating and
accessing account information in accordance with embodiments of the
invention.
[0012] FIG. 2 illustrates exemplary data provided to and stored in
the database system of FIG. 1.
[0013] FIGS. 3-5 are flow diagrams illustrating several processes
used within the database system of FIG. 1, for locating and
accessing account data.
[0014] FIG. 6 is a block diagram of one suitable scoring model and
process for use in one embodiment of the invention.
[0015] FIG. 7 is a flow diagram illustrating a process used within
the database system of FIG. 1, in accordance with an alternative
embodiment.
[0016] FIG. 8 is a block diagram of a computer system upon which
various devices, systems, and processes described in conjunction
with FIGS. 1-7 may be implemented.
DETAILED DESCRIPTION OF THE INVENTION
[0017] 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).
[0018] In certain described embodiments, a system for locating
assets may receive two different types of requests to locate assets
(such as financial accounts). One such request may be an asset
search request, and the other may be an asset verification
request.
[0019] 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.
[0020] 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.
[0021] Embodiments of the present invention support alternative
asset 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) 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 other 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, student financial assistance,
credit checks, and delinquent tax collections.
[0022] Other embodiments may support asset 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 to identify and assess the risk of fraud
when processing a beneficiary's request for benefits.
[0023] 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 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, 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.
[0024] Turning now to FIG. 1, there is shown an exemplary system
100 for locating and accessing account information. The account
information is stored and processed at a central account database
system 110 having a database device 120 for storing account
information and an account database management system (DBMS) 130
for managing the data in database 120 (e.g., the DBMS stores,
retrieves, arranges, sorts and processes the data in the database).
As illustrated, the data used to populate the database 120 is
obtained from a number of financial institutions 140. In addition,
requests to access the account data stored in database system 110
may be received from government agencies 150 (e.g., to establish
qualification for benefits), from mortgage companies 160 (e.g., to
verify account balances) and from other entities 170 (e.g., needing
to locate and access account data for various reasons, such as
creditworthiness, ability to supply funds, or debt or asset
verification).
[0025] 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 such as PayPal accounts; (iii) online
gaming accounts, such as Farmville or SecondLife 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.
[0026] It should be appreciated that, while the embodiment
illustrated in FIG. 1 assumes financial institutions will
contribute data, and that government agencies, mortgage companies
and other entities will access the data, in some cases the
financial institutions 140 may also access account data in system
110 (e.g., as part of a loan application) and government agencies
150, mortgage companies 160 and other entities 170 may contribute
account data (e.g., benefits accounts and mortgage accounts). Thus,
in their broadest sense, financial institutions 140 may represent
any kind of institution or other entity maintaining an account or
asset (financial or otherwise), and government agencies 150,
mortgage companies 160 and other entities 170 may represent any
kind of entity (governmental, commercial or otherwise) wanting to
locate and/or verify accounts or assets that are maintained at
various institutions.
[0027] FIG. 2 illustrates exemplary data provided to (and stored
in) the database system 110 by each of the financial institutions
140. In this particular example, the data comprises account data
for a bank account, and thus includes the following data fields
(collectively designated as 202 in FIG. 2):
Routing and Transit Number (RTN)
Account Number
[0028] Account Type (e.g., checking, savings, certificate of
deposit, investment account)
Social Security Number (SSN)/Tax ID Number
[0029] 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
Email Address(es) of Account Holder
Phone Number
[0030] Date of Birth (DOB) of Account holder Data date (date of
receipt by system 110)
Current Balance
[0031] Average Balance (e.g., average balance over the past 30
days)
Interest Paid
[0032] Maturity Date (e.g., maturity date for a certificate of
deposit)
[0033] As should be appreciated, FIG. 2 shows data for only one
account, and in practice there would be many accounts from many
institutions stored in database system 110.
[0034] As seen in FIG. 2, the data includes an initial transfer 210
for each of the data fields (current and historical information at
the time of the initial transfer), and subsequent periodic
transfers 212-1 through 212-n for most of the same data fields (to
keep the data updated). In FIG. 2, the illustrated periodic data
transfers 212-1 through 212-n are each transferred and stored daily
(Day 1, Day 2, Day 3, etc., up to the current day). Such a frequent
updating is generally preferred, although is some embodiments and
applications a less frequent updating might be acceptable. The
updated data fields are illustrated as including the same data as
the initial transfer, other than the RTN, Account Number and
Account Type fields, since it is assumed, for purposes of the
described embodiment, that these three data fields will remain
unchanged over the life of the account.
[0035] Also, FIG. 2 shows each updated daily transfer of data
(212-1 through 212-n) having all fields 202 in database system 110
populated with data (other than RTN, Account Number and Account
Type). However, in practice, much of that data will not change
between transfers, and so database system 110 may be managed so
that only the changed data in a daily transfer will be stored (in
such case, especially if updates are daily, many of the data fields
illustrated in FIG. 2 would in fact not be populated in order to
efficiently mange storage space and minimize unnecessary data
processing). This filtering of unnecessary data could be
implemented in one embodiment by database system 110 being
programmed to review data fields as they are received from the
financial institutions 140 and to remove data that has not changed
since the day before. In another embodiment, the financial
institutions 140 may have systems on-site and programmed to remove
unchanged data before it is transmitted.
[0036] 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.
[0037] 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-related 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) 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. 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 FIG. 2) that indicates
risk factors have been identified for the account. The risk marker
could be as simple as a "yes" or "no," and in other embodiments
could be a code to indicate whether the risk is relevant to
specific categories of requesters, such a government benefits
program, a mortgage company, a creditor, or some other request
category. It should be appreciated that some factors (e.g., recent
patterns of transfers out) would be relevant to a request from a
government benefits program, and the same factors may have little
or no relevance to a mortgage company. In embodiments where the
system has collected risk-related data (in addition to the risk
marker itself), such data could be stored in a separate table of
data (to be described later), and would only be accessed if the
risk is relevant to the purpose of the request.
[0038] FIGS. 3, 4 and 5 illustrate processes for responding to
requests received at the database system 110. Before proceeding
with descriptions of such Figures, it should be noted that a
request to the system 110 may have a standard format and include
information pertinent to the person (for whom the account data is
sought), such as account holder SSN, name, address, and bank
name(s) and account numbers (if any). However, information needed
to identify any accounts for the person could be minimal and, in
one embodiment, might only be an SSN. For example, in the case of
an account search request (e.g., by a government agency doing a
search for accounts), the SSN may be the only identifier provided
and used to locate accounts. Other relevant data can be provided,
if desired, to provide more accuracy and confirm matches (name,
address, and even bank account numbers--if supplied by the person),
and generally more information will be returned and its accuracy
improved when more personal information is provided. In the case of
an account verification request (e.g., by a mortgage company
wanting to verify balance information supplied by an applicant),
account numbers would typically be provided (for redundancy) as
identifiers in addition to an SSN, to make sure that any account
identified by an applicant is considered in verifying account
balances. But even in that example, the system 110 could process
and return account information based on a social security number.
However, with either type of request, it should be appreciated that
in some embodiments the requester may only provide a social
security number as an identifier, and information can be returned
by system 100 based only on that identifier and not relying on
account numbers or other data concerning the account holder.
[0039] Turning now to FIG. 3, a request for an account search
(e.g., locating for a government agency any account at any
institution belonging to a person that is the subject of the
search) is received by system 110 (step 310). The system determines
if the request is valid (step 312). Such a determination could be
based on several possible factors, such as whether the requester is
authorized (e.g., the requester has, in advance, been properly
authorized as an entity or individual), whether the request has
been properly formatted (e.g., a personal identifier, such as a
provided SSN, has the correct number of digits or is recognized as
a valid SSN), and whether the device transmitting the request is
recognized (e.g., from previous transactions or has been authorized
in advance by the requester). If the request is not valid, the
requester is notified (and the request is not processed further).
If the request is valid, the system next determines whether there
is an account in the database system 110 that matches the provided
personal identifier (step 314). If the personal identifier does not
identify any account, the requester is notified and the process
ends (as indicated in FIG. 3). Alternatively, other steps can be
taken (point "A" in the drawings) to identify accounts without
using a social security number (such steps will be described
shortly in conjunction with FIG. 4).
[0040] If accounts are identified with the provided personal
identifier, the system looks for matches with other data (if any)
provided by the requester (step 320). 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 320, then the data for the identified account is retrieved,
step 322. If risk data is also to be provided (if available and
requested, step 324), then the risk data is retrieved (step 326)
and the retrieved data is provided to the requester as part of the
response (step 330).
[0041] As mentioned above, in some cases, even if an account is not
identified with a personal identifier such as an SSN (step 314),
the system 110 can be programmed to locate accounts using other
personal information of the person in question. This is illustrated
in FIG. 4, where the system 100 first looks for other matches of
personal information (e.g., names, addresses, phone numbers), and
if there is match (step 412), the system may also analyze the match
to verify that the information is for same account holder (step
414). As an example, this last step can be based on the amount of
information matched, so that with two or more pieces of personal
information being the same (both name and address for an account
are the same as the name and address in the request) a match is
indicated. In this example, if there is there is no match, the
system 100 notifies the requester and the search ends. As an
additional step, the system 100 may also further review any account
where a match is made and verified at steps 412 and 414, identify
the personal identifier such as an SSN for that verified account,
and then also identify any other accounts in the database (at any
institution) having the same personal identifier as the verified
account (step 416). This process then returns to the process in
FIG. 3, with any retrieved data provided back to the requester.
[0042] FIG. 5 illustrates a process similar to that of FIG. 3, but
rather than an account search request, this process is used to
respond to an account verification request (e.g., from a mortgage
company). An account verification request is received by the system
110 (step 510) and the system determines if the request is valid
(step 512). The system then determines if any accounts stored in
the system are identified by the provided personal identifier such
as an SSN, step 514. Since many account verification requests will
also include account numbers provided by an applicant, the system
determines if any accounts are identified by provided account
numbers (step 516). The accounts that are identified (either at
step 514 or step 516) are retrieved (step 522).
[0043] The system notifies the requester as to the nature of the
matches (step 520). 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 520 (as indicated in FIG. 5). Alternatively,
additional steps can be taken (point "A" in the drawings) to
identify accounts (such additional steps are shown in, and were
earlier described in conjunction with, FIG. 4). If, at step 520,
there has been a match of only one of the personal identifier or
account number, the requester is so notified (as to what identifier
or information resulted in the match) and the process continues to
the earlier described step 522 (account data for the identified
account is retrieved).
[0044] If risk data is also to be provided (if available and
requested, step 524), then the risk data is retrieved (step 526)
and the retrieved data is provided to the requester as part of the
response (step 530).
[0045] While FIGS. 3, 4 and 5 illustrate the search or verification
process ending when no accounts are indentified or found within
system 110 (e.g., at steps 314, 412, and 520), it should be
appreciated that other methods could be employed to respond to a
search or verification request, in the event of an account not
being found within system 110. For example, in one embodiment, when
a requester provides account numbers and one or more of those
account numbers are not found in the system 110, the system 110
could be configured to forward those account numbers to the
institution(s) where they are maintained (e.g., using an RTN or
bank name provided with the request), and then to respond to the
requestor with any information supplied directly by the
institution. In some cases, information supplied directly by the
financial institution may supplement the account data retrieved
from database 120 and, in those cases, both the information from
the financial institution and account data retrieved from database
may be provided in a response to the requestor (e.g., at steps 330
and 530). The methods just described could be accomplished
automatically (on a batched basis or in real-time) in response an
account number not being found in system 110 or, alternatively,
could be accomplished with the assistance of personnel involved in
operating system 110. In yet another embodiment, the system 110
could be electronically linked to the systems at various financial
institutions 140 and configured to remotely search account
databases at those institutions, so that as the system 110 searches
its own database 120 it could likewise search (simultaneously or
otherwise) the databases of the linked financial institutions and
combine any located data in a response to a requester.
[0046] 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. This is illustrated by the scoring model and
process of FIG. 6, where the account data for any given account is
provided to scoring logic 610. The scoring logic, which could be
implemented within the database management system 130 or a separate
processing system (not shown) within central account database
system 110, may use a statistical or rules-based analysis (other
forms of analysis, such as artificial neural networks, could also
be used) to develop a score (examples of analysis used by scoring
logic 610 will be given shortly). In some instances, the account
data may not be sufficient to generate a score (e.g., the account
has recently been opened, or there has been very little or no
account activity). In such case, the account data may be stored in
a hold account queue 612 until sufficient data is available. In
other cases, where there is sufficient data, the account data and
resulting risk score may be stored in a scored account queue 614,
which includes a risk score table 620.
[0047] The process of FIG. 6 also illustrates that the scoring
process may be continuous. As additional new account data arrives
for any accounts represented in the hold account queue 612, the
account data is reapplied to the scoring logic 610. The additional
data is also used in association with already scored accounts in
scored account queue 614 to make fresh calculations of risk data
for those accounts. That is, the scoring logic 610 is periodically
re-run using updated account data (along with previous data in the
scored account queue 614), and the table 620 is updated with new
scores as they are generated. Over time, most of the accounts
represented in the hold account queue 612 should migrate to the
scored account queue 614. Eventually, most active accounts will
have risk scores in table 620.
[0048] In FIG. 6, risk scores 622 in table 620 are illustrated as
numerical (from 1 to 100), with "100" representing the highest risk
and "1" representing the lowest. Of course other, simpler forms of
risk data could be generated, such as only three risk levels
("low," "medium," and "high"). Also, risk reasons 624 are
illustrated in table 620. Such reasons (or codes for such reasons)
could be based on risk factors described below.
[0049] The following tables illustrate scoring analysis (exemplary
risk factors and corresponding risk impact) that could be used in
scoring logic 610, 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.
TABLE-US-00001 Risk Score Analysis Account Search-Government
Benefits Factors Risk Impact Transfer In/Out Patterns Frequent
deposits and withdrawals - (money flow in and out increased risk
(likely attempt to keep of account) balances low) Infrequent
transactions - decreased risk Dates of Withdrawals (in Withdrawals
within 6 months of begin date - relation to program increased risk
(likely attempt to conceal requirements specifying assets) a begin
date for balances Withdrawals more than 6 moths prior to to be
below program begin date - decreased risk threshold amount) Amount
of Withdrawals At least one withdrawal - increased risk (e.g. total
withdrawals of No withdrawals - decreased risk $1000 during past 5
years) Number/Nature of Located 5 or more located accounts (likely
attempt to Accounts spread assets) - increased risk Less than 5
located accounts - decreased risk Accounts located but not
identified by beneficiary - increased risk Names, addresses, phone
Matches with suspected fraudsters - numbers on account (in
increased risk addition to those of No matches with suspected
fraudsters - beneficiary) decreased risk Account SSN/Name Match SSN
or name for account do not match those provided in request -
increased risk Both SSN and name for account match those provided
in request - decreased risk
TABLE-US-00002 Risk Score Analysis Mortgage Application Factors
Risk Impact Saving Pattern Infrequent deposits during each month
(not a likely consistent "saver") - increased risk Frequent and
consistent deposits - decreased risk Added Signer Signer address
same as applicant - decreased risk Signer address at zip code
distant from applicant - increased risk Name or SSN of new signer
matches suspected fraudsters - increased risk No matches with
suspected fraudsters - decreased risk Recent deposits Large
Amount(s) - increased risk Small amount(s) - decreased risk
[0050] Also, because the system 100 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.
[0051] 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.
[0052] 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.
[0053] For example, furnishing a plurality of personal identifiers
such as an SSN and name and address (and requiring that an
indentified 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.
[0054] A simplified illustration of one such process is seen in
FIG. 7. The process of FIG. 7 is similar to (and has steps
corresponding to those of) of FIG. 3, but more specifically
involves a search request (step 710) from a government agency for
an individual or entity contemplated as the subject of a subpoena.
As described in conjunction with FIG. 3, the system 110 determines
whether the request is valid, step 712, and whether any accounts
associated with a personal identifier of the subject (such as a
social security number) can be identified, step 714. If there is no
SSN match, then the requester is notified (and the process may
end), but optionally, other steps can be undertaken to identify
accounts without using a social security number (steps proceeding
from point "A" in the drawings, using a process similar to that
described earlier in conjunction with FIGS. 3 and 4). At step 720
other account data (e.g., name and address, if any, provided with
the request) may be used to provide additional confirmation that
the identified account is matched to the person that is the subject
of the search. While not illustrated in FIG. 7, linking and network
analysis can optionally be used to identify additional accounts and
provide other information that may have some association with the
subject of the contemplated subpoena, as will be described in
connection with a specific example to follow shortly. Account data
for any identified account is retrieved at step 722. As in FIG. 3,
if risk data associated with an identified account is available
(step 724), it may also be retrieved (step 726). Among other
things, risk data may be used to determine the need for quickly
executing a subpoena and then seizing an account that has a high
risk of being involved in fraudulent activity (and that may be
likely to have its balance quickly depleted/transferred by the
fraudster/account holder). The retrieved data is provided (step
730), and a subpoena is prepared and executed at step 732 by the
government agency.
[0055] 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 indentifying
information corresponding to accounts for which Vito is a
signatory.
[0056] 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.
[0057] 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.
[0058] FIG. 8 is a block diagram illustrating an exemplary computer
system upon which embodiments of the present invention may be
implemented. This example illustrates a computer system 800 such as
may be used, in whole, in part, or with various modifications, to
provide the functions of the central database system 110, including
the DBMS 130 and the scoring logic 610, as well as other components
and functions of the invention described herein.
[0059] The computer system 800 is shown comprising hardware
elements that may be electrically coupled via a bus 890. The
hardware elements may include one or more central processing units
810, one or more input devices 820 (e.g., a mouse, a keyboard,
etc.), and one or more output devices 830 (e.g., a display device,
a printer, etc.). The computer system 800 may also include one or
more storage devices 840, 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) 850 for accessing the storage
device(s) 840. By way of example, storage device(s) 840 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.
[0060] The computer system 800 may additionally include a
communications system 860 (e.g., a modem, a network card--wireless
or wired, an infra-red communication device, a Bluetooth.TM.
device, a near field communications (NFC) device, a cellular
communication device, etc.) The communications system 860 may
permit data to be exchanged with a network, system, computer,
mobile device and/or other component as described earlier. The
system 800 also includes working memory 880, which may include RAM
and ROM devices as described above. In some embodiments, the
computer system 800 may also include a processing acceleration unit
870, which can include a digital signal processor, a
special-purpose processor and/or the like.
[0061] The computer system 800 may also comprise software elements,
shown as being located within a working memory 880, including an
operating system 884 and/or other code 888. Software code 888 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 800, can be
used in implementing the processes seen in FIGS. 3-7.
[0062] It should be appreciated that alternative embodiments of a
computer system 800 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).
[0063] 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.
[0064] Moreover, while the various flows and processes described
herein (e.g., those illustrated in FIG. 3-7) are described in a
particular order for ease of description, unless the context
dictates otherwise, various procedures may be reordered, added,
and/or omitted in accordance with various embodiments of the
invention. Moreover, the procedures described with respect to one
method or process may be incorporated within other described
methods or processes; likewise, system components described
according to a particular structural architecture and/or with
respect to one system may be organized in alternative structural
architectures and/or incorporated within other described systems.
Hence, while various embodiments may be described with (or without)
certain features for ease of description and to illustrate
exemplary features, the various components and/or features
described herein with respect to a particular embodiment can be
substituted, added, and/or subtracted to provide other embodiments,
unless the context dictates otherwise. Consequently, although the
invention has been described with respect to exemplary embodiments,
it will be appreciated that the invention is intended to cover all
modifications and equivalents within the scope of the following
claims.
* * * * *