Fraudulent transaction identification system

Embodiments of the present invention are directed to methods, systems and computer program products for identifying fraudulent transactions. In general, transaction information is inputted into the system and an address is received from such information. A database is then queried to determine if the address already exists in the database. A determination is made whether or not the transaction is suspicious in response to the address existing in the database entry. Alternatively, in response to the address not existing in the database entry, a determination is made as to whether or not the transaction is suspicious based on a geocode. A geocode is a geographic location or coordinates of an address.

BACKGROUND

Currently, banks allow their customers to order foreign banknotes and perform other transactions via the internet. However, fraud has been committed by persons who order banknotes from another's bank account or make changes to the shipping addresses of existing banknote orders. Such persons may repeatedly use the same shipping address location for the banknote delivery. There is no current method to determine if a transaction is suspicious if repeated orders are being shipped to the same address or location within certain time intervals.

Thus, there is a need to identify if a transaction is suspicious or fraudulent based on repeated orders being received for shipment to the same address or location within a certain time interval.

SUMMARY

In accordance with an aspect of the present invention, a method for identifying fraudulent transactions is disclosed. The method includes receiving an address and creating a hash code from the address. Next a database is queried to determine if the hash code exists in the database. A determination is made as to whether or not the transaction is suspicious in response to the hash code existing in the database. Further, in response to the hash code not existing in the database, a determination is made as to whether or not the transaction is suspicious based on a geocode. The geocode is an address code identifying a location of the address such that every address location has only a single geocode associated therewith.

In accordance with another aspect of the present invention, another method for identifying fraudulent transactions is disclosed. The method includes inputting transaction information into the system and an address is received from such information. A database is then queried to determine if the address already exists in the database. A determination is made whether or not the transaction is suspicious in response to the address existing in the database entry. Alternatively, in response to the address not existing in the database entry, a determination is made as to whether or not the transaction is suspicious based on a geocode. A geocode is a geographic location of an address.

In accordance with another aspect of the present invention, a system for identifying fraudulent transactions is disclosed. The system includes a computer processor and a data structure operable on the processor to present a graphical user interface for a user to input transaction information, where the transaction information includes an address. Another data structure operable on the processor creates a hash code from the address. Yet another data structure operable on the processor queries a database to determine if the hash code exists in the database. The system also includes a data structure operable on the processor to determine whether or not the transaction is suspicious in response to the hash code existing in the database. The system further includes a data structure operable on the processor to determine whether or not the transaction is suspicious based on a geocode in response to the hash code not existing in the database.

In accordance with another aspect of the present invention, a computer-readable medium having computer executable instructions for performing a method for identifying fraudulent transactions is disclosed. The method includes inputting transaction information the system and an address is received from such information. A database is then queried to determine if the address already exists in the database. A determination is made whether or not the transaction is suspicious in response to the address existing in the database entry. Alternatively, in response to the address not existing in the database entry, a determination is made as to whether or not the transaction is suspicious based on a geocode.

In one embodiment, the geocode is an address code identifying a location of the address such that every address location has only a single geocode associated therewith. In another embodiment, the geocode is a geographic location of an address.

Other aspects and features of the present invention, as defined by the claims, will become apparent to those skilled in the art upon review of the following non-limited detailed description of the invention in conjunction with the accompanying figures.

DETAILED DESCRIPTION

Embodiments of the present invention are directed to methods, systems and computer program products for identifying fraudulent transactions.FIGS. 1,2A-B (collectivelyFIG. 2) andFIG. 3illustrate methods, systems and computer program products for detecting suspicious transactions using geocodes. Such methods and systems are described in more detail below with regard toFIGS. 1-3.

FIG. 1illustrates a system100which allows for a transaction to occur and includes a fraudulent transaction identification system110. The transaction is any action, such as a financial transaction, a business transaction, a consumer transaction, etc., that is performed by a user102. The user102is any entity who desires to conduct banking transactions, such as a customer of a bank, other persons, a company, an electronic device, or any other entity. It should be understood that this disclosure is not only applicable to transactions, but is also applicable to any other situation where an address is employed in an activity. For example, embodiments of the present invention is applicable to internet fraud, voter fraud, postal fraud, governmental programs/activities, programs/offers limited to one offer per household, or any other activity (whether a transaction or not) where a person's or company's address is an element of the activity.

To begin the transaction, a user102enters into a transaction interface106via a network104. The network104is any type of network, such as a wide area network (WAN), a local area network (LAN), the Internet, a wireless network, a Bluetooth network, and the like. The transaction interface106is any type of interface to which the transaction is initiated, such as a software interface, internet website, paper, and the like. The transaction interface106includes one or more graphical user interfaces which will be described later with regard toFIG. 3. In any event, a user102will input transaction information into the transaction interface106, including the type of transaction to be performed, the transaction money amount, an address to receive a transactional product (such as a banknote), the entity's name, the bank account and other like information. After such information is entered into the transaction interface106, the transaction interface106transmits the information to the financial institution. Although any type of transaction or other activity may be included in the embodiments of the present disclosure, various embodiments are directed to a transaction involving a banknote transaction (e.g. a foreign banknote transaction).

Once the transaction information is received by the financial institution, a fraudulent transaction check108occurs. Each fraudulent transaction check108includes different criteria regarding the transaction that must be met in order for the transaction and/or address inputted in the transaction to be deemed suspicious or fraudulent. According to one embodiment, each of the fraud check criteria is defined by a financial institution. In one embodiment, any transactions that are returned as suspicious (such as via the method200), then the system100may perform fraudulent checks108on that transaction to further determine if the transaction is fraudulent. The fraudulent check108may occur with or without the suspicious check (e.g. method200) or the suspicious check (e.g. method200) may be an add-on component to the fraudulent checks108. In any event, the fraudulent check may determine whether or not the transaction is suspicious and/or if the transaction is fraudulent.

One of the fraud transaction checks108includes a fraudulent transaction check using geocodes as shown in block110. Embodiments of the fraudulent transaction check using geocodes110are substantially described below with respect toFIGS. 2A and 2B(collectivelyFIG. 2). The fraudulent transaction check using geocodes110may access a geocode source112which is also described later with regard toFIG. 2. Regardless, after the fraudulent transaction check using geocodes110and/or the fraudulent transaction checks108are performed, the system100proceeds to decision block114.

In decision block114, the system100determines whether or not the transaction is suspicious and/or fraudulent. Such determination is made with information received from fraudulent transaction check using geocodes110and/or the fraudulent transaction check108. If the transaction is determined to not be suspicious, then normal processing occurs, as shown in block116.

However, if the transaction is determined to be suspicious in blocks108or110, then the transaction is stored in a database118as a suspicious transaction. Additionally, if the transaction is returned suspicious, the suspicious transaction may be immediately reviewed by the financial entity or any other entity so that appropriate action may be taken, as shown in block120. In some embodiments, appropriate action includes determining which bank accounts the banknote is being withdrawn from and/or to, determining the address of the fraudulent transaction, determining the entity in charge of the suspicious transaction, taking legal or policing action against the entity in charge, cancelling transactions, flagging certain bank accounts, flagging/saving suspicious IP addresses, blocking access to certain bank accounts and the like.

Turning now toFIGS. 2A and 2B, embodiments of a method200for the fraudulent transaction check using geocodes110are illustrated. The method200is performed as block110ofFIG. 1.

Referring back toFIG. 2A, as represented in block202, the previously inputted address of the transaction is received by the system100. In block204, a hash code (hash1) is created based on the inputted address. A hash code is a way of computing a small digest numeric key from a long string or even an arbitrary clump of bytes. A hash code is produced by hash function which may be a pre-defined procedure or mathematical formula for turning some kind of data into a relatively small integer that may serve as an index into an array. For example, the address “3157 43rdStreet, Astoria, N.Y. 11103” may be converted into hash code “D345FQ1.” By way of another example, the address “3157 43 RD ST, Astoria, N.Y. 11103” may be converted into hash code “2F65RF1.” Further, the address “3157 43RD STREET APT 1, LONG ISLAND CITY N.Y. 11103” may have a hash code of “O4TE113.” As can be readily seen, each of these addresses is similar in that they may all have the same physical mailing location where a banknote may be delivered. However, each of these addresses has a different hash code based on the differences in the address wording.

After the hash code is created in block204, the method200advances to block206to check if the created hash code (hash1) exists in the database208. The database208includes multiple entries and each entry includes a geocode, hash code, an address, flags and other information related to the transactions and/or previous transactions. Thus, in block206, the database208is queried to determine if hash1already exists in one of the database entries and a value of “yes” or “no” is returned to block212.

As represented in block212, a determination is made whether or not hash1exists in the database based on the value received by block206. If hash1does not exist in the database208, the method200branches to block213which continues at block213ofFIG. 2B, which is discussed in more depth below with regard toFIG. 2B. By hash1not existing in the database, this indicates that the address is a newly entered or worded address. If hash1already exists in the database, then the method200branches to block214.

As represented in block214, the address geocode flag is retrieved from the database208under the same database entry associated with hash1. In some embodiments, elements in the database entry associated with hash1are also retrieved in block214, such as the address, geocode and other transaction information to determine if the address is suspicious. In any event, the information retrieved from the database in block214is analyzed to determine whether the transaction is suspicious or not. In one embodiment, the address is deemed suspicious if the retrieved address geocode flag has a value which indicates that the transaction is suspicious. In another embodiment, the address is deemed suspicious if the address retrieved from the database208does not match the inputted address. In yet another embodiment, the address is deemed suspicious if the inputted address has been the subject of repeated transactions within a certain predetermined time interval. Other pre-determined criteria may also determine whether or not the address is suspicious.

It should be understood that the transaction, the address or a combination thereof may be determined to be suspicious. Where the transaction is determined to be suspicious, the address may also, or alternatively, be deemed to be suspicious and vice versa.

In block210, according to one embodiment, one or more addresses are manually flagged as suspicious so that when these addresses are checked for suspicious activity, they will automatically return a flag indicating that the address and/or transaction is suspicious. Such manual entry allows a financial institution to monitor entities and addresses and/or flag certain known addresses as addresses to automatically mark as suspicious even though the system may not deem these addresses to be suspicious based solely on the inputted address.

In decision block216, the method200may branch to block218if the address is not determined to be suspicious. In such instance, the transaction is processed normally, as shown in block116ofFIG. 1.

Alternatively, in block216, if the transaction is determined to be suspicious, the method200will branch to block220where the transaction is returned as a suspicious transaction and the address of the suspicious transaction is flagged in the database208. As previously described in block114ofFIG. 1, if the address if returned as suspicious, the address is saved in database118as a suspicious transaction and the bank may take appropriate action, as shown in block120.

As mentioned above with regard to decision block212ofFIG. 2A, if hash1does not exist in database212, then the method200branches to block213. Referring toFIG. 2B, block213directs the method200to block222where a geocode is obtained.

A geocode (i.e. a geospatial entity object (GEO) code) is a representation format of a geospatial coordinate measurement used to provide a standard representation of an exact geospatial point three-dimensional location at, below or above the surface of the earth. The process of geocoding includes converting an address (e.g. “3157 43rdStreet, Astoria, N.Y. 11103”) into geographic coordinates (e.g. <−73.915782, 40.758853, 0>). Using the examples presented above, the addresses “3157 43rdStreet, Astoria, N.Y. 11103”, “3157 43 RD ST, Astoria, N.Y. 11103”, and “3157 43RD STREET APT 1, LONG ISLAND CITY N.Y. 11103” all have the same geocode coordinates of (−73.915782, 40.758853, 0) because they are all located at the same physical location. In one embodiment, a geocode is a representation of one or more of the following: latitude, longitude, altitude, date, time, coordinate reference system, internet protocol address, geocode registry format number, and other geospatial attributes.

The geocode is obtained by retrieving the geocode from a geocode source112. In one embodiment, the geocode source112is a service provider that provides a geocode based on the address that is provided. For example, the geocode service provider could be Google Maps API, which can be found at http://maps.google.com, http://code.google.com/apis/maps/, or http://earth.google.com/. To retrieve a geocode, an HTTP request can be sent to the geocode service provider and the geocode service provider will return the geocode coordinates. The geocode service may also be accessed by using Google's GclientGeocoder object. Example of a simple KML code which will determine geocode includes:<kml xmlns=“http://earth.google.com/kml/2.0”><Response><name>3157 43rdStreet, Astoria, N.Y. 11103</name><Status><code>200</code><request>geocode</request></Status></Response></kml>

In this example, the geocode will be returned in KML or XML code. Other programming languages may also be employed. In another embodiment, the geocode source is a geocode database that is stored on a server. Additionally, other means for obtaining a geocode in block222includes generating a geocode or other means for retrieving a geocode. In any event, the geocode that is obtained is based on the address that has previously been inputted by the user102.

After obtaining the geocode, the method200advances to decision block224where a determination is made whether or not the geocode was successfully retrieved or obtained. If the geocode is not successfully retrieved or obtained in decision block224, the method200branches to block228which returns the inputted address as invalid. At this point, the user102may re-enter the address or other transaction information in block106via network104, as previously described with regard toFIG. 1.

On the other hand, if the geocode is successfully retrieved or obtained in block224ofFIG. 2B, the method200then will branch to block230where the geocode is cross-referenced to the database208to determine whether or not the geocode exists in database208. To make such determination, a request is sent to the database208and, in response, a value of either “yes” (i.e. the geocode exists in the database) or “no” (i.e. the geocode does not exist in the database) is returned in block230.

In decision block234, the determination of whether the geocode does or does not exist in the database directs the method to either block236or block240. If the geocode is not determined to exist in the database, the method200branches to block236where the transaction is deemed valid and a new database entry, including geocode, hash code, address, etc., is stored in the database208. Since the transaction is deemed to be valid and therefore not fraudulent, the transaction is returned as valid and not suspicious, as shown in block238. At this point, normal processing of the transaction occurs, as previously mentioned in block116ofFIG. 1.

On the other hand, in decision block234, if the geocode does exist in the database, the method200branches to block240. In this case, potentially fraudulent activity is identified because hash1was not in the database but the geocode associated with hash1is in the database. In block240, the hash code (hash2) that is associated with the geocode in the database entry is retrieved from the database208. To retrieve hash2, a request is sent to the database208to receive the hash code associated with the same database entry with the geocode. Hash2is then returned from the database, as shown in block240. As previously mentioned with respect to block206ofFIG. 2A, hash1was not in the database and therefore, hash1must be different from hash2.

In decision block242, a determination is made whether or not the address is suspicious. In making this determination, the system will verify that hash2is not equal to hash1. If these two hashes are not equal, then the transaction and/or address is flagged as suspicious and the originally inputted address is flagged in the database208. In one embodiment, predetermined actions are automatically taken in response to suspicious transaction being identified, such as presenting an alert, cancelling the transaction, notifying the financial institution and/or a bank account owner, delaying the transaction for review, monitoring the transaction, and the like.

As previously discussed with reference toFIG. 1, once the address is returned as suspicious, appropriate action will be taken and the transaction is saved in database118as a suspicious transaction.

FIG. 3is a block schematic diagram of an example of a system300for fraudulent transaction identification in accordance with another embodiment of the present invention. The system300includes a module for fraudulent transaction identification system302operable on a computer system304or similar device of a user306or a client. Alternatively, in addition to the module for fraudulent transaction identification system302on the user's computer system304or client, the system300may include a module for fraudulent transaction identification system308operable on a server310and accessible by the user306or client304via a network312. The methods100and200may be embodied or performed by the module for fraudulent transaction identification system302or the server module for fraudulent identification transaction system308. For example, the methods100and200may be performed by the module for fraudulent transaction identification system302. In another embodiment of the invention, the methods100and200may be performed by the server module for fraudulent transaction identification system308. In a further embodiment of the present invention, some of the features or functions of the methods100and200may be performed by the module for fraudulent transaction identification system302on the user's computer system304and other features or functions of the methods100and200may be performed on the server module for fraudulent transaction identification system308.

One or more geocode servers or databases314may be operable on the server310and may be accessible by the system300via the network312. The geocode server and/or database312may be accessed by the server module for fraudulent transaction identification system308. As previously mentioned, the geocode server and/or database314,314′ may be a service provider or database that may return a geocode based on an inputted address. As shown, the geocode server and/or database314′ may be operable on the server310or the geocode server and/or database314may be completely separate from server310. The network312may be the Internet, a private network or other network as previously mentioned. Each computer system304′ may be similar to the exemplary computer system304and associated components as illustrated inFIG. 3.

The module for fraudulent transaction identification system302and/or308may be a self contained system with imbedded logic, decision making, state based operations and other functions that may operate to perform fraudulent transaction checks.

The module for fraudulent transaction identification system302may be stored on a file system316or memory of a computer system304. The module for fraudulent transaction identification system302may be accessed from the file system316and run on a processor318associated with the computer system304.

The module for fraudulent transaction identification system302includes a module for allowing entry of transaction information319. The module for allowing entry of transaction information319allows the user306to input various transaction information associated with a transaction such as the address, bank accounts, user information and the like as previously described with respect toFIGS. 1 and 2. The module for allowing entry of transaction information319is accessed or activated whenever the user306desires to input information and calls other module such as the graphical user interface340as described below. At this point, entry of transaction information is received by the module for fraudulent transaction identification system308on the server310via the network312.

The module for fraudulent transaction identification system302also includes a module for acquiring user information321. This module321acquires information about the user based on the user's input of data, such as the user's IP address, user's inputted information and the like. Such information may be useful in tracking down a person who commits a fraudulent transaction.

The user's computer system304also includes a display330and a speaker332or speaker system. Any graphical user interfaces340associated with the module for fraudulent transaction identification system308is presented on the display330. Speaker332may present any voice or other auditory system signals or information to the user306. The users computer system304also includes one or more input devices, output devices or combination input and output devices collectively I/O devices334. The I/O devices334include a keyboard, computer pointing device or similar means to control input of information for the module for the transaction identification system as described herein. The I/O devices334also include disk drives or devices for reading computer media including computer readable or computer operable instructions.

The server module for fraudulent transaction identification system308includes a module for receiving transaction information342. The module for receiving transaction information342receives any data any computer or server such as geocode information, address information, hash codes, user information and the like. Inputted transaction information is received, for example, from the module for allowing entry or transaction information319located on the user's computer304. The module for receiving transaction information342is activated or accessed by other modules in the fraudulent transaction identification system module308. For example, the module for receiving transaction information342transmits the received address to the module for creating hash344, the module for updating the address database348or any other module. The module for receiving transaction information342is operable in block202ofFIG. 2Awhere the addresses are received.

The server module for fraudulent transaction identification system308also includes a module for creating hash344. The module for creating a hash344operates to create a hash code based on the address information received from the module for receiving transaction information342. As previously described with respect to block204ofFIG. 2, the hash code is a numerical formula to create a short data code based on a long string of information or characters. The module for creating hash344is accessed and activated by other modules in the system300. After creating of each hash code, the module for creating hash344transmits the hash code into the address database346and saves it in each entry.

The server module for fraudulent transaction identification system308further includes an address database346which is a series of entries based on transaction information received. Each database entry includes transaction information, including the address, the hash, geocode, flags, previous transaction information, or any other transaction information. The address database is stored on the server310or an external server314. The address database346is similar or the same database as database208as shown inFIGS. 2A and 2B.

The server module for fraudulent transaction identification system308also includes a module for updating address database348. The module for updating address database348works to update the address database346after receiving information to be stored in the address database346. The module for updating the address database348may also retrieve information from the address database346and/or transfer that information to other modules in the system300.

The server module for fraudulent transaction identification system308also includes a module for querying and returning information from the address database350. This module350queries the address database346to obtain one or more entries in the database346. One or more entries will be transmitted to and received by the module350. The entry that has been retrieved by the module350is then transferred to another module in the system300for further processing.

The server module for fraudulent transaction identification system308also includes a module for obtaining a geocode352. As previously discussed with respect toFIGS. 1 and 2, a geocode may be obtained from various sources including from a geocode database314, from the service provider314′, by creating a geocode or by any other means. The module for obtaining a geocode352retrieves the geocode information and works with the various service providers to obtain the geocode and transfer the geocode to another module in the system300for further processing.

The server module for fraudulent transaction identification system308also includes a module for determining if the address is suspicious354. This module354is activated in blocks114ofFIG. 1and blocks216and242ofFIG. 2. The module for determining if the address is suspicious354may return a value indicating the transaction is suspicious if: 1) the address is flagged as suspicious, 2) if the address is hash code (hash2) retrieved from the database is not equal to the hash code (hash1) that has been inputted previously, as shown in block242, 3) a pre-defined criteria by a system operator is not met, 4) repeated transactions are performed to the same address or geocode within a certain time interval, and the like. The module for determining if the address is suspicious354returns the determination that the address is suspicious or not suspicious to a foreign information system (FIS), for example, as shown inFIG. 1. Block114ofFIG. 1then transfers either a “yes” value or a “no” value from decision block114to indicate that the transaction is suspicious or not suspicious, respectively. In addition, the module for determining the address is suspicious354stores the suspicious transaction information in the suspicious transaction database356on the server310.

The suspicious transactions356is a database stored on the server module for fraudulent transaction identification system308. The suspicious transactions database356is equivalent to or similar to the suspicious transaction database118shown inFIG. 1, as previously described.

The module for fraudulent transaction identification system302,308includes graphical user interfaces340,340′, as previously mentioned. The module for fraudulent transaction identification system302,308allows one or more predetermined graphical user interfaces340to be presented to the user306in order for the user306to input address information, transaction information, user information and the like into the system300. The graphical user interfaces340are predetermined and/or presented in response to the user306indicating the user306would like to perform a transaction. The predetermined graphical user interfaces340are generated by the module for fraudulent transaction identification system302,308and are presented on the display330at the computer system304. Graphical user interfaces340also include graphical user interfaces that permit the user306to view the result and query any of the databases and/or generate reports and/or standardize documents.