US7440915B1 - Method, system, and computer-readable medium for reducing payee fraud - Google Patents

Method, system, and computer-readable medium for reducing payee fraud Download PDF

Info

Publication number
US7440915B1
US7440915B1 US11/941,636 US94163607A US7440915B1 US 7440915 B1 US7440915 B1 US 7440915B1 US 94163607 A US94163607 A US 94163607A US 7440915 B1 US7440915 B1 US 7440915B1
Authority
US
United States
Prior art keywords
entity
risk assessment
payee
request
data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
US11/941,636
Inventor
Glen Ulrich
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
US Bank NA
Original Assignee
US Bancorp Licensing Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by US Bancorp Licensing Inc filed Critical US Bancorp Licensing Inc
Priority to US11/941,636 priority Critical patent/US7440915B1/en
Assigned to U.S. BANCORP LICENSING, INC. reassignment U.S. BANCORP LICENSING, INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: ULRICH, GLEN
Application granted granted Critical
Publication of US7440915B1 publication Critical patent/US7440915B1/en
Assigned to U.S. BANK, NATIONAL ASSOCIATION reassignment U.S. BANK, NATIONAL ASSOCIATION ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: U.S. BANCORP LICENSING, INC.
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G06Q20/4016—Transaction verification involving fraud or risk level assessment in transaction processing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/12—Accounting

Definitions

  • the subject of the disclosure relates generally to a method, system, and computer-readable medium for reducing payee fraud. More specifically, the disclosure relates to a negative payee database which retains profiles and assessments of negative payees such that an informed decision can be made regarding whether to grant a request for payment to a payee.
  • a payee can refer to an individual or entity that is to receive payment from another individual or entity (i.e., the payor).
  • the payor can initiate the payment through a paper check, an electronic transfer, over the telephone, or by any other method known to those in the financial industry.
  • a first payor may utilize an electronic transfer to provide a payment to a cable company payee for cable services.
  • a second payor may use a debit card to purchase a product from a department store payee.
  • payees utilize fraudulent techniques to receive funds to which they are not entitled.
  • Fraudulent transactions can result in a loss of funds for an innocent payor and/or a financial institution such as a bank.
  • a payor may use a network browser to locate a network (such as the Internet) based store which purports to sell electronic goods.
  • the network based store may be a fake store which attempts to fraudulently accept payment for goods with no intent of ever delivering the goods to the payor.
  • the payor can locate a good bargain on an electronic item within the network based store and use his/her bank issued debit card to pay for the electronic item over the network.
  • the bank which is also unaware that the store is a fake, can transfer funds from the payor's account to the fraudulent payee. As a result, the bank, the payor, or both have lost funds.
  • There are numerous other examples of fraudulent financial transactions in which a fraudulent payee is able to receive undeserved funds.
  • An exemplary computer-readable medium has computer-readable instructions stored thereon that, upon execution by a processor, cause the processor to receive fraud data from a first data source, wherein the fraud data is related to a fraudulent transaction of an entity.
  • a first data element corresponding to the entity is also received from the first data source.
  • the first data element is correlated with the fraudulent transaction to form an entity profile of the entity.
  • the first data element and a second data element corresponding to the entity are received from a second data source.
  • the second data element is correlated with the entity profile based on the first data element.
  • a transaction risk assessment request is received based on a request for payment to a payee, wherein the transaction risk assessment request includes a payee identifier.
  • a transaction risk assessment is generated based at least in part on the entity profile and at least in part on the payee identifier.
  • An exemplary system for reducing fraudulent transactions includes a profile generator and a payment module.
  • the profile generator is configured to receive fraud data from a first data source, where the fraud data is related to a fraudulent transaction of an entity.
  • a first data element corresponding to the entity is also received from the first data source.
  • An entity profile is generated, wherein the entity profile comprises an association between the fraud data and the first data element.
  • the first data element and a second data element corresponding to the entity are received from a second data source.
  • the second data element is correlated with the entity profile based on the first data element.
  • An entity profile risk assessment is generated for the entity profile, wherein the entity profile risk assessment is based at least in part on the fraud data.
  • the payment module is configured to receive a transaction risk assessment request based on a request for payment, where the request for payment comprises a monetary request to a payee.
  • the transaction risk assessment request includes a payee identifier corresponding to the payee.
  • the payee identifier is compared to the entity profile to generate a confidence score.
  • a transaction risk assessment is generated based at least in part on the entity profile risk assessment and at least in part on the confidence score.
  • FIG. 1 is a flow diagram illustrating operations performed by a payee fraud reduction system in accordance with an exemplary embodiment.
  • FIG. 2 is a flow diagram illustrating operations performed by the payee fraud reduction system in response to a request for payment in accordance with an exemplary embodiment.
  • FIG. 3 is a block diagram illustrating a payee fraud reduction system in accordance with an exemplary embodiment.
  • a negative payee database or other storage mechanism can be used to store profiles of payees who have attempted fraudulent transactions, been associated with fraud, elicited questionable behavior, etc. in the past.
  • Each payee in the negative payee database can have a profile associated with him/her/it.
  • the profile can include one or more data elements (i.e., identifiers such as a name, alias, address, etc.) such that the payee can be identified in multiple ways.
  • the profile can also include a risk assessment based on the number and/or severity of fraudulent transactions associated with the payee, the likelihood that the payee was involved in the fraudulent transaction, etc.
  • Financial institutions can determine whether to grant a payment request to the payee based at least in part on the risk assessment.
  • FIG. 1 is a flow diagram illustrating operations performed by a payee fraud reduction system in accordance with an exemplary embodiment. In alternative embodiments, fewer, additional, or different operations may be performed.
  • a first data element is received from a first data source.
  • the first data source may be a financial institution, the Office of Foreign Assets Control (OFAC), the United States Postal Inspection Service (USPIS), an internal countermeasure system (ICMS) of a corporate entity, a law enforcement agency, a dedicated fraud detection agency, a credit reporting agency, a consortium member, a private institution, or any other information source which accumulates reliable data regarding an entity.
  • entity can refer to a business such as a corporation, limited liability company, partnership, etc., or an individual.
  • the first data element can be a piece of information associated with a particular entity/individual.
  • the first data element may be a name of the entity, an alias of the entity, a postal address of the entity, a delivery address of the entity, an entity type (i.e., individual, corporation, limited liability company, etc.), a telephone number of the entity, a fax number of the entity, a driver's license number of the entity, a state identification number of the entity, an account routing number of the entity, an account number of the entity, a social security number of the entity, a tax identification number of the entity, an e-mail address of the entity, an e-mail or web domain name of the entity, a credit card number of the entity, an Internet protocol (IP) address of the entity, known associates of the entity, an employer of the entity, a dollar amount of previous payments associated with the entity, and a familial relationship of the entity.
  • IP Internet protocol
  • payee fraud reduction system receives fraud data from the first data source.
  • the first data element and the fraud data may be received at the same time.
  • the first data source may provide the fraud data and a name (i.e., data element) associated with the fraud data.
  • the first data source may provide the fraud data and a postal address associated with the fraud data.
  • the USPIS may provide a street address known to be used as a mail drop.
  • the fraud data can be any information identifying a fraudulent act or transaction which was committed, a fraudulent act which was attempted, a criminal charge for a fraudulent act, a criminal conviction for a fraudulent act, an association with an entity that committed, attempted, was charged with, or was convicted of a fraudulent act, etc.
  • the fraud data can also include any fraud factors regarding or associated with the fraudulent act. Examples of fraudulent acts may include financial account takeover or manipulation, pharming schemes, counterfeiting, kiting schemes, phishing schemes, bad check schemes, check alteration schemes, any other crimes of a financial nature or committed against a financial institution, and/or any other factors found to be a reliable indicator of fraud.
  • a plurality of fraud data items can be received.
  • the plurality of fraud data items may have at least one data element in common.
  • a risk value is assigned to the received fraud data.
  • the risk value can be based on any of a number of fraud factors, including the type of fraudulent act indicated in the received fraud data, a severity of the fraudulent act, a role of the entity in the fraudulent act, the recentness of the fraudulent act, the reliability of the data source which provided the fraud data, and/or the likelihood that the fraudulent act was actually committed or attempted.
  • the fraud factors associated with the received fraud data can also be received from the first data source.
  • the fraud factors may be provided from one or more other data sources.
  • a financial institution may provide information regarding the existence of a fraudulent act, and a law enforcement agency may provide specific details regarding the fraudulent act.
  • the risk value can be an accumulated point value, where a low risk value corresponds to low risk and a high risk value corresponds to high risk. The amount of points associated with the fraudulent act can be based on the fraud factors described above.
  • a first fraud factor may be the type of fraudulent act.
  • Check alteration may be assigned a first point value, forgery may be assigned a second point value, establishment of a phishing website may be assigned a third point value, and so on.
  • a second fraud factor can be the severity of the fraudulent act. Financial fraud of less than $100 may be assigned a first point value, fraud which is greater than or equal to $100 and less than $1000 may be assigned a second point value, fraud which is greater than or equal to $1000 and less than $10,000 may be assigned a third point value, and fraud which is greater than or equal to $10,000 may be assigned a fourth point value.
  • a third fraud factor may be the role of the entity in the fraudulent act.
  • Involvement as a sole perpetrator may be assigned a first point value
  • involvement as an accomplice may be assigned a second point value
  • involvement as a conspirator may be assigned a third point value, and so on.
  • a family, work, or personal relationship with a fraudulent entity may be a assigned a point value.
  • the point value(s) assigned for one or more relationships with fraudulent entities can be based on the number of such relationships and/or the closeness of such relationships.
  • fraudulent acts which took place in the last year may be assigned a second point value
  • fraudulent acts which took place in the last 5 years may be assigned a third point value, and so on.
  • a fifth fraud factor may be the likelihood that the alleged fraudulent act actually took place. For example, a first point value may be assigned to fraudulent acts for which a criminal conviction occurred, a second point value may be assigned to fraudulent acts for which a criminal charge was filed, a third point value may be assigned to fraudulent acts for which no criminal charge was filed, and so on.
  • a sixth fraud factor may be the victim of the fraudulent act. For example, if the system is maintained by a financial institution, a first point value may be assigned if the fraudulent act was against the financial institution, a second point value may be assigned if the fraudulent act was against any other financial institution, and a third point value may be assigned if the fraudulent act was against a non-financial institution.
  • the system may be maintained and used by a consortium having a plurality of consortium members.
  • a first point value may be assigned if the fraudulent act was against a specific consortium member
  • a second point value may be assigned if the fraudulent act was against any other consortium member
  • a third point value may be assigned if the fraudulent act was against a financial institution which is not a consortium member
  • a fourth point value may be assigned if the fraudulent act was against a non-financial institution which is not a consortium member.
  • any other factors may be considered for determination of the risk value.
  • the points attributed to each of the fraud factors associated with the fraudulent act can be added or otherwise mathematically manipulated to obtain the risk value. If information regarding a particular fraud factor is unavailable, a default value may be used. The default value can be zero, or any other predetermined value. In one embodiment, the default value associated with the unknown fraud factor may be based on other known fraud factors. For example, if the recentness of the fraudulent act is unknown, a first default point value for the recentness factor may be used if the amount at issue was less than $100, and a second default point value may be used if the amount at issue was greater than $10,000. In an alternative embodiment, any other type of point and/or scoring system may be used to obtain the risk value of a fraudulent act.
  • an entity profile based on the first data element and the fraud data is created.
  • the entity profile can be an association between the fraud data and the first data element.
  • the entity profile can also include other data elements associated with the entity such that the likelihood of identification of the entity is increased.
  • the other data elements can be obtained from a plurality of distinct data sources.
  • the entity profile is stored in a negative payee storage module.
  • the negative payee storage module can be a database or any other type of storage module known to those of skill in the art.
  • a second data element is received from a second data source.
  • the second data element may be received in response to a data element request.
  • the payee fraud reduction system (or system) may receive the first data element and the fraud data from the first data source.
  • the system can issue a data element request to one or more data sources in an attempt to expand the entity profile of the entity.
  • additional data elements can increase the likelihood that the entity will be identified during a financial transaction.
  • an entity profile may only include fraud data and a street address as a result of a fraudulent act committed by an individual A at the street address. With such a limited entity profile, individual A may still be able to conduct financial transactions without detection by the system. However, if the entity profile also includes individual A's name, the system can be on alert that individual A has been involved with a fraudulent act.
  • the second data element may be received as a random or scheduled information update from the second data source.
  • the system determines whether there is a link between the entity profile and the second data element.
  • the system can include a plurality of entity profiles corresponding to a plurality of entities.
  • the link can be identified by searching the plurality of entity profiles to locate common data elements.
  • the first data source may provide information regarding a fraudulent transaction (i.e., fraud data) that was committed by John Doe, and an entity profile corresponding to John Doe and the fraud data can be created.
  • the data elements provided by the second data source may include the name John Doe and a street address where John Doe lives.
  • the system can search the plurality of entity profiles to identify the name John Doe as a link between the information provided from the first data source and the information provided from the second data source.
  • the system may use an additional verification procedure to ensure that the John Doe living at the street address is the same John Doe from the entity profile.
  • the second data element(s) are correlated with the entity profile in an operation 140 .
  • the updated entity profile is more likely to flag a financial transaction involving John Doe.
  • the second data element(s) are stored for future evaluation in an operation 135 .
  • the future evaluation can be conducted when additional entity profiles are created by the system to ensure that the entity profiles include a maximal number of data elements associated with the entity.
  • the second data element(s) may be discarded if a link is not found.
  • the first data element can be provided with the second data element, and the first data element can be used to link the second data element to the entity profile.
  • the entity profile may include a plurality of fraudulent acts associated with the entity. Fraud data regarding the plurality of fraudulent acts may be received from one or more data sources.
  • the system can assign an entity profile risk assessment to the entity profile.
  • the entity profile risk assessment can be based at least in part on the number of fraudulent transactions associated with the entity profile and the risk values assigned to each of the fraudulent transactions.
  • the entity profile risk assessment may also be based on the reliability of the data elements associated with the profile entity, the reliability of the data sources which provided the data elements, and/or the likelihood that the data elements are actually associated with the entity.
  • a first entity profile may have a first fraudulent act, a second fraudulent act, and three data elements associated therewith.
  • the entity profile risk assessment may be determined in real time upon receipt of a request for payment to a payee.
  • the entity profile risk assessment can be determined as part of a transaction risk assessment which is used to ultimately determine whether a request for payment should be granted.
  • the transaction risk assessment can be based on payee identifiers which are associated with the payee. For example, the transaction risk assessment can be based on the number of payee identifiers which match data elements from the entity profile. A larger number of matching pairs can imply a higher probability that the payee corresponds to the entity from the entity profile.
  • the transaction risk assessment can also be based on the degree of similarity between the payee identifiers and the data elements from the entity profile.
  • the system can recognize that the names ‘Bob’ and ‘Robert’ have a high degree of similarity, even though they have a different spelling.
  • the degree of commonality of the payee identifier and/or the data element it is compared to can also be a factor upon which the transaction risk assessment is based. For example, a payee identifier name of ‘John Smith’ which matches the name ‘John Smith’ in an entity profile may be accorded less weight than a match of the name ‘Jebediah Crunch.’
  • FIG. 2 is a flow diagram illustrating operations performed by the payee fraud reduction system in response to a request for payment in accordance with an exemplary embodiment. In alternative embodiments, fewer, additional, or different operations may be performed.
  • a request for payment or transaction risk assessment request is received by the system.
  • the request for payment can be initiated by a payor through a channel of a financial institution.
  • the request for payment may be a request by the payor to transfer owed funds to a payee.
  • the request for payment may be initiated by the payee (i.e., the payee may attempt to cash a check or otherwise receive funds from the payor), or by any other institution designated to receive requests for payment and forward them to the system.
  • the channel of the financial institution can be any payment origination channel through which funds can be transferred to a payee.
  • the channel may be a telephone banking channel, an Internet (or network) banking channel, a wire transfer channel, an account-to-account transfer channel, a bill pay channel, a money order transaction channel, an automated clearinghouse (ACH) channel, a paper check transaction channel, an inter-bank transfer channel, a person-to-person channel, a mobile payment channel, etc.
  • ACH automated clearinghouse
  • the system may be incorporated within the financial institution such that the request for payment is automatically received by the system upon receipt by the financial institution.
  • the system may be maintained by a separate entity which is distinct from the financial institution.
  • the system can provide fraud detection and payment recommendation services to a plurality of financial or other institutions (i.e., a consortium), and/or receive fraud data and data elements from members of the consortium.
  • the system may receive a transaction risk assessment request based on a request for payment.
  • the transaction risk assessment request can include one or more payee identifiers associated with the request for payment.
  • the transaction risk assessment request can be provided by a financial or other institution which receives the request for payment.
  • any other requester including the payee, can provide the transaction risk assessment request.
  • one or more payee identifiers associated with the request for payment are identified.
  • the potential categories of payee identifiers can correspond to the potential categories of data elements as described with reference to FIG. 1 .
  • the name of the payee can be a first payee identifier which potentially corresponds to a name data element
  • an address of the payee can be a second payee identifier which potentially corresponds to an address data element
  • a telephone number of the payee can be a third payee identifier which potentially corresponds to a telephone number data element, and so on.
  • the payee identifier can be any other type of information which can be used to associate a payee with an entity profile.
  • the payee identifier(s) can be provided by the payee and/or the payor depending on the type of financial transaction and the banking channel through which the financial transaction is conducted.
  • the system determines whether there is a link between the identified payee identifier(s) and any of the entity profiles accessible to the system.
  • the process for determining whether a link exists can be similar to the process for identifying links between data elements and entity profiles as described above with reference to FIG. 1 .
  • the plurality of entity profiles can be searched to determine whether the identified payee identifier(s) match any data elements associated with any of the entity profiles. If a plurality of payee identifiers have been received, the system can search for each of the payee identifiers within the entity profiles.
  • the system can grant the request for payment in an operation 215 .
  • the system may just notify the requestor that no matches were found.
  • a confidence value can be determined.
  • the confidence value which may be a percentage, can be the likelihood that a payee associated with the request for payment is the entity associated with an entity profile.
  • the confidence value can be based on the number of payee identifiers which match an entity profile and/or the quality of the matches.
  • a transaction risk assessment can be generated for each entity profile for which a link was identified in operation 210 .
  • the transaction risk assessment(s) can be generated in real time, and can be based on any risk value(s) and/or an entity profile risk assessment associated with the entity profile(s) as described with reference to FIG. 1 .
  • the transaction risk assessment(s) can be also based on the confidence value (i.e., the likelihood that the payee actually corresponds to the entity associated with the entity profile). If multiple entity profiles are identified as being linked to a payee, the system can generate an individual transaction risk assessment for each identified entity profile.
  • the plurality of individual transaction risk assessments can be averaged to determine the transaction risk assessment.
  • the entity profile risk assessments of the plurality of entity profiles may be averaged, and the average multiplied by the confidence value (or average confidence value) to obtain the transaction risk assessment.
  • the transaction risk assessment may be the highest individual risk assessment, the lowest individual risk assessment, a median individual risk assessment, or based on any other mathematical manipulation(s) of the plurality of individual risk assessments.
  • the system determines if the transaction risk assessment(s) satisfy a risk threshold in an operation 220 .
  • the risk threshold can be determined by the system, one or more financial institutions, a governmental entity, or any other source. In one embodiment in which the system serves a plurality of financial institutions, different financial institutions may have different risk thresholds. If the risk threshold is satisfied for all of the entity profiles for which a link was identified, the system grants the request for payment in operation 215 . Alternatively, the system may just notify the bank that the risk threshold is satisfied for all identified entity profiles. If the risk threshold is not satisfied for any of the identified entity profiles, the system denies the request for payment in an operation 225 .
  • the system may provide the transaction risk assessment to a financial institution or other system user, and the financial institution (or other system user) can make the decision of whether to grant or deny the request for payment.
  • the transaction risk assessment may be used as a factor within the system user's larger fraud reduction system, and the larger fraud reduction system can make the decision regarding whether to grant or deny the request for payment. It is important to understand that the system described herein is not limited to use by financial institutions. The system can also be used by department stores, decoupled debit card providers, and/or any other businesses or individuals that initiate payments. In an exemplary embodiment, any of the operations performed by the system can be embodied as instructions stored in a computer-readable medium.
  • the instructions can cause the processor to perform the above-described operations.
  • the system may provide an audit report which identifies a reason for the denial of the request for payment or a reason for the unfavorable transaction risk assessment.
  • the audit report may identify the fraudulent act(s) of the payee, the data source(s) which provided fraud data corresponding the fraudulent act(s), and/or any other information relevant to the transaction risk assessment.
  • FIG. 3 is a block diagram illustrating a payee fraud reduction system in accordance with an exemplary embodiment.
  • a first data source 300 , a second data source 305 , and a third data source 310 can provide data elements and/or fraud data to a profile generator 315 of the payee fraud reduction system (system).
  • the data elements and/or fraud data can also be provided to a negative payee storage module 320 .
  • Profile generator 315 can receive data element(s) and fraud data corresponding to a given entity.
  • Profile generator 315 can use the data element(s) and fraud data to create an entity profile which can be stored in negative payee storage module 320 .
  • Profile generator 315 can also assign a risk value to individual fraudulent transactions and/or assign an entity profile risk assessment to the entity profile.
  • profile generator 315 can identify links between existing entity profiles and additional data elements which are received from first data source 300 , second data source 305 , and third data source 310 . If links are identified, profile generator 315 can update the entity
  • Payment module 325 can receive requests for payment from a financial institution 330 .
  • the requests for payment may be received from an entity, such as a governmental entity or a corporation, which is not a financial institution.
  • Financial institution 330 can receive the request for payment from a payment requester 335 .
  • Payment requester 335 may be a payee or a payor depending on the transaction.
  • the request for payment can be a request for a funds transfer from the payor to the payee.
  • Payment module 325 can identify payee identifier(s) associated with the payee of the request for payment, and determine whether the identified payee identifier(s) match any data elements associated with an entity profile.
  • payment module 325 can grant the payment request or simply inform financial institution 330 , depending on the embodiment. If there are any entity profiles with a data element which matches one or more payee identifiers of the payee, payment module 325 can generate a transaction risk assessment for each of the identified entity profiles. Depending on the embodiment, payment module 325 may also be used to generate risk values and/or entity profile risk assessments for profile entities stored in negative payee storage module 320 . Payment module 325 can compare the transaction risk assessment with a risk threshold to determine whether the risk threshold is satisfied. If the risk threshold is satisfied, payment module 325 can grant the request for payment or inform financial institution 330 that the request for payment has been cleared.
  • payment module 325 can deny the request for payment or inform financial institution 330 that there is a problem.
  • Financial institution 330 can inform payment requester 335 whether the request for payment is allowed or denied.
  • financial institution 330 can receive the transaction risk assessment and make a determination whether to grant or deny the request for payment based at least in part on the transaction risk assessment.
  • the system of FIG. 3 can also include a reviewer for reviewing denied requests for payment.
  • Incorrect denials of payment can cause problems for customers of financial institution 330 (i.e., a deadline for payment of a bill may be missed), and can result in a negative reputation for financial institution 330 .
  • the reviewer can be an individual who manually reviews the denied requests and makes a final decision based on additional research and/or previous knowledge. For example, a denial of payment may be based on a street address which was associated with a fraudulent act of an entity. The reviewer may be able to determine that the entity which committed the fraudulent act has moved and that the new resident (i.e., the payee of the current request for payment) has no association with fraud.
  • the reviewer can also ensure that the entity profile stored in negative payee storage module 320 is updated to reflect the change of address.
  • the payor may be notified of a potential fraudulent payee and asked whether he/she/it would like to proceed with the transaction.
  • payment requester 335 can be a payor who uses a debit card to pay a payee for an online purchase of goods.
  • the request for payment can result from the debit card transaction.
  • Financial institution 330 can be a bank which manages the financial accounts of the payor and receives the request for payment.
  • the request for payment to the payee can include at least a financial account number of the payee, a company name of the payee, a street address of the payee, and a telephone number of the payee.
  • the bank can submit the request for payment, including the payee identifiers (i.e., the financial account number, company name, street address, and telephone number of the payee) to payment module 325 .
  • Payment module 325 can perform a search of negative payee storage module 320 to determine whether any of the payee identifiers match any data elements stored within negative payee storage module 320 .
  • Payment module 325 can determine that the street address of the payee matches the street address contained in the above-described entity profile.
  • Payment module 325 can generate a confidence score based on the likelihood that the payee is the entity associated with the entity profile. Based at least in part on the confidence score and the entity profile risk assessment of the entity profile, payment module 320 can generate a transaction risk assessment for the request for payment. If the transaction risk assessment does not satisfy a risk threshold used by the bank, payment module 320 can deny the request for payment. In one embodiment, a reviewer can review the denial for request for payment to help ensure that the denial is not in error. If the transaction risk assessment for the entity profile satisfies the risk threshold, the request for payment can be granted.

Abstract

An exemplary method for reducing fraudulent transactions includes receiving fraud data from a first data source, wherein the fraud data is related to a fraudulent transaction of an entity. A first data element corresponding to the entity is also received from the first data source. The first data element is correlated with the fraudulent transaction of the entity to form an entity profile. The first data element and a second data element corresponding to the entity are received from a second data source. The second data element is correlated with the entity profile based on the first data element. A transaction risk assessment request based on a request for payment to a payee is received, wherein the transaction risk assessment request includes a payee identifier. A transaction risk assessment is generated based at least in part on the entity profile and at least in part on the payee identifier.

Description

FIELD
The subject of the disclosure relates generally to a method, system, and computer-readable medium for reducing payee fraud. More specifically, the disclosure relates to a negative payee database which retains profiles and assessments of negative payees such that an informed decision can be made regarding whether to grant a request for payment to a payee.
BACKGROUND
In the financial industry, a payee can refer to an individual or entity that is to receive payment from another individual or entity (i.e., the payor). The payor can initiate the payment through a paper check, an electronic transfer, over the telephone, or by any other method known to those in the financial industry. For example, a first payor may utilize an electronic transfer to provide a payment to a cable company payee for cable services. Similarly, a second payor may use a debit card to purchase a product from a department store payee. Unfortunately, there are many instances in which payees utilize fraudulent techniques to receive funds to which they are not entitled.
Fraudulent transactions can result in a loss of funds for an innocent payor and/or a financial institution such as a bank. As an example, a payor may use a network browser to locate a network (such as the Internet) based store which purports to sell electronic goods. Unbeknownst to the payor, the network based store may be a fake store which attempts to fraudulently accept payment for goods with no intent of ever delivering the goods to the payor. The payor can locate a good bargain on an electronic item within the network based store and use his/her bank issued debit card to pay for the electronic item over the network. The bank, which is also unaware that the store is a fake, can transfer funds from the payor's account to the fraudulent payee. As a result, the bank, the payor, or both have lost funds. There are numerous other examples of fraudulent financial transactions in which a fraudulent payee is able to receive undeserved funds.
Unfortunately, traditional fraud detection and prevention systems are not able to efficiently and effectively identify fraudulent acts on the part of payees. While disparate information regarding fraudulent acts of payees may exist, traditional systems are not able to organize and utilize the information to prevent future fraudulent acts from the same payee. Thus, there is a need for a fraud detection system which is able to utilize a plurality of sources to effectively identify fraudulent payees. Further, there is a need for a fraud prevention system which is able to effectively identify and deny financial transactions involving fraudulent payees.
SUMMARY
An exemplary method for reducing fraudulent transactions includes receiving fraud data from a first data source, wherein the fraud data is related to a fraudulent transaction of an entity. A first data element corresponding to the entity is also received from the first data source. The first data element is correlated with the fraudulent transaction of the entity to form an entity profile. The first data element and a second data element corresponding to the entity are received from a second data source. The second data element is correlated with the entity profile based on the first data element. A transaction risk assessment request based on a request for payment to a payee is received, wherein the transaction risk assessment request includes a payee identifier. A transaction risk assessment is generated based at least in part on the entity profile and at least in part on the payee identifier.
An exemplary computer-readable medium has computer-readable instructions stored thereon that, upon execution by a processor, cause the processor to receive fraud data from a first data source, wherein the fraud data is related to a fraudulent transaction of an entity. A first data element corresponding to the entity is also received from the first data source. The first data element is correlated with the fraudulent transaction to form an entity profile of the entity. The first data element and a second data element corresponding to the entity are received from a second data source. The second data element is correlated with the entity profile based on the first data element. A transaction risk assessment request is received based on a request for payment to a payee, wherein the transaction risk assessment request includes a payee identifier. A transaction risk assessment is generated based at least in part on the entity profile and at least in part on the payee identifier.
An exemplary system for reducing fraudulent transactions includes a profile generator and a payment module. The profile generator is configured to receive fraud data from a first data source, where the fraud data is related to a fraudulent transaction of an entity. A first data element corresponding to the entity is also received from the first data source. An entity profile is generated, wherein the entity profile comprises an association between the fraud data and the first data element. The first data element and a second data element corresponding to the entity are received from a second data source. The second data element is correlated with the entity profile based on the first data element. An entity profile risk assessment is generated for the entity profile, wherein the entity profile risk assessment is based at least in part on the fraud data. The payment module is configured to receive a transaction risk assessment request based on a request for payment, where the request for payment comprises a monetary request to a payee. The transaction risk assessment request includes a payee identifier corresponding to the payee. The payee identifier is compared to the entity profile to generate a confidence score. A transaction risk assessment is generated based at least in part on the entity profile risk assessment and at least in part on the confidence score.
Other principal features and advantages will become apparent to those skilled in the art upon review of the following drawings, the detailed description, and the appended claims.
BRIEF DESCRIPTION OF THE DRAWINGS
Exemplary embodiments will hereafter be described with reference to the accompanying drawings.
FIG. 1 is a flow diagram illustrating operations performed by a payee fraud reduction system in accordance with an exemplary embodiment.
FIG. 2 is a flow diagram illustrating operations performed by the payee fraud reduction system in response to a request for payment in accordance with an exemplary embodiment.
FIG. 3 is a block diagram illustrating a payee fraud reduction system in accordance with an exemplary embodiment.
 DETAILED DESCRIPTION
Described herein is a method, system, and computer-readable medium for reducing fraudulent financial transactions. A negative payee database or other storage mechanism can be used to store profiles of payees who have attempted fraudulent transactions, been associated with fraud, elicited questionable behavior, etc. in the past. Each payee in the negative payee database can have a profile associated with him/her/it. The profile can include one or more data elements (i.e., identifiers such as a name, alias, address, etc.) such that the payee can be identified in multiple ways. The profile can also include a risk assessment based on the number and/or severity of fraudulent transactions associated with the payee, the likelihood that the payee was involved in the fraudulent transaction, etc. Financial institutions can determine whether to grant a payment request to the payee based at least in part on the risk assessment.
FIG. 1 is a flow diagram illustrating operations performed by a payee fraud reduction system in accordance with an exemplary embodiment. In alternative embodiments, fewer, additional, or different operations may be performed. In an operation 100, a first data element is received from a first data source. The first data source may be a financial institution, the Office of Foreign Assets Control (OFAC), the United States Postal Inspection Service (USPIS), an internal countermeasure system (ICMS) of a corporate entity, a law enforcement agency, a dedicated fraud detection agency, a credit reporting agency, a consortium member, a private institution, or any other information source which accumulates reliable data regarding an entity. As used herein, entity can refer to a business such as a corporation, limited liability company, partnership, etc., or an individual.
In an exemplary embodiment, the first data element can be a piece of information associated with a particular entity/individual. For example, the first data element may be a name of the entity, an alias of the entity, a postal address of the entity, a delivery address of the entity, an entity type (i.e., individual, corporation, limited liability company, etc.), a telephone number of the entity, a fax number of the entity, a driver's license number of the entity, a state identification number of the entity, an account routing number of the entity, an account number of the entity, a social security number of the entity, a tax identification number of the entity, an e-mail address of the entity, an e-mail or web domain name of the entity, a credit card number of the entity, an Internet protocol (IP) address of the entity, known associates of the entity, an employer of the entity, a dollar amount of previous payments associated with the entity, and a familial relationship of the entity. Alternatively, the first data element can be any other type of information which can be used to help identify a given entity.
In an operation 105, payee fraud reduction system receives fraud data from the first data source. In an exemplary embodiment, the first data element and the fraud data may be received at the same time. For example, the first data source may provide the fraud data and a name (i.e., data element) associated with the fraud data. Alternatively, the first data source may provide the fraud data and a postal address associated with the fraud data. For example, the USPIS may provide a street address known to be used as a mail drop. The fraud data can be any information identifying a fraudulent act or transaction which was committed, a fraudulent act which was attempted, a criminal charge for a fraudulent act, a criminal conviction for a fraudulent act, an association with an entity that committed, attempted, was charged with, or was convicted of a fraudulent act, etc. The fraud data can also include any fraud factors regarding or associated with the fraudulent act. Examples of fraudulent acts may include financial account takeover or manipulation, pharming schemes, counterfeiting, kiting schemes, phishing schemes, bad check schemes, check alteration schemes, any other crimes of a financial nature or committed against a financial institution, and/or any other factors found to be a reliable indicator of fraud. In one embodiment, a plurality of fraud data items can be received. The plurality of fraud data items may have at least one data element in common.
In an operation 110, a risk value is assigned to the received fraud data. The risk value can be based on any of a number of fraud factors, including the type of fraudulent act indicated in the received fraud data, a severity of the fraudulent act, a role of the entity in the fraudulent act, the recentness of the fraudulent act, the reliability of the data source which provided the fraud data, and/or the likelihood that the fraudulent act was actually committed or attempted. In an exemplary embodiment, the fraud factors associated with the received fraud data can also be received from the first data source. Alternatively, the fraud factors may be provided from one or more other data sources. For example, a financial institution may provide information regarding the existence of a fraudulent act, and a law enforcement agency may provide specific details regarding the fraudulent act. In one embodiment, the risk value can be an accumulated point value, where a low risk value corresponds to low risk and a high risk value corresponds to high risk. The amount of points associated with the fraudulent act can be based on the fraud factors described above.
As an example, a first fraud factor may be the type of fraudulent act. Check alteration may be assigned a first point value, forgery may be assigned a second point value, establishment of a phishing website may be assigned a third point value, and so on. A second fraud factor can be the severity of the fraudulent act. Financial fraud of less than $100 may be assigned a first point value, fraud which is greater than or equal to $100 and less than $1000 may be assigned a second point value, fraud which is greater than or equal to $1000 and less than $10,000 may be assigned a third point value, and fraud which is greater than or equal to $10,000 may be assigned a fourth point value. A third fraud factor may be the role of the entity in the fraudulent act. Involvement as a sole perpetrator may be assigned a first point value, involvement as an accomplice may be assigned a second point value, involvement as a conspirator may be assigned a third point value, and so on. In addition, a family, work, or personal relationship with a fraudulent entity may be a assigned a point value. The point value(s) assigned for one or more relationships with fraudulent entities can be based on the number of such relationships and/or the closeness of such relationships. A fourth fraud factor may be the recentness of the fraudulent act. Fraudulent acts which took place in the last six months may be assigned a first point value, fraudulent acts which took place in the last year may be assigned a second point value, fraudulent acts which took place in the last 5 years may be assigned a third point value, and so on. A fifth fraud factor may be the likelihood that the alleged fraudulent act actually took place. For example, a first point value may be assigned to fraudulent acts for which a criminal conviction occurred, a second point value may be assigned to fraudulent acts for which a criminal charge was filed, a third point value may be assigned to fraudulent acts for which no criminal charge was filed, and so on. A sixth fraud factor may be the victim of the fraudulent act. For example, if the system is maintained by a financial institution, a first point value may be assigned if the fraudulent act was against the financial institution, a second point value may be assigned if the fraudulent act was against any other financial institution, and a third point value may be assigned if the fraudulent act was against a non-financial institution. Alternatively, the system may be maintained and used by a consortium having a plurality of consortium members. In such an embodiment, a first point value may be assigned if the fraudulent act was against a specific consortium member, a second point value may be assigned if the fraudulent act was against any other consortium member, a third point value may be assigned if the fraudulent act was against a financial institution which is not a consortium member, and a fourth point value may be assigned if the fraudulent act was against a non-financial institution which is not a consortium member. In an alternative embodiment, any other factors may be considered for determination of the risk value.
In an exemplary embodiment, the points attributed to each of the fraud factors associated with the fraudulent act can be added or otherwise mathematically manipulated to obtain the risk value. If information regarding a particular fraud factor is unavailable, a default value may be used. The default value can be zero, or any other predetermined value. In one embodiment, the default value associated with the unknown fraud factor may be based on other known fraud factors. For example, if the recentness of the fraudulent act is unknown, a first default point value for the recentness factor may be used if the amount at issue was less than $100, and a second default point value may be used if the amount at issue was greater than $10,000. In an alternative embodiment, any other type of point and/or scoring system may be used to obtain the risk value of a fraudulent act.
In an operation 115, an entity profile based on the first data element and the fraud data is created. In an exemplary embodiment, the entity profile can be an association between the fraud data and the first data element. As described in more detail below, the entity profile can also include other data elements associated with the entity such that the likelihood of identification of the entity is increased. The other data elements can be obtained from a plurality of distinct data sources. In an operation 120, the entity profile is stored in a negative payee storage module. The negative payee storage module can be a database or any other type of storage module known to those of skill in the art.
In an operation 125, a second data element is received from a second data source. In one embodiment, the second data element may be received in response to a data element request. For example, the payee fraud reduction system (or system) may receive the first data element and the fraud data from the first data source. The system can issue a data element request to one or more data sources in an attempt to expand the entity profile of the entity. In an exemplary embodiment, additional data elements can increase the likelihood that the entity will be identified during a financial transaction. As an example, an entity profile may only include fraud data and a street address as a result of a fraudulent act committed by an individual A at the street address. With such a limited entity profile, individual A may still be able to conduct financial transactions without detection by the system. However, if the entity profile also includes individual A's name, the system can be on alert that individual A has been involved with a fraudulent act. In an alternative embodiment, the second data element may be received as a random or scheduled information update from the second data source.
In an operation 130, the system determines whether there is a link between the entity profile and the second data element. In an exemplary embodiment, the system can include a plurality of entity profiles corresponding to a plurality of entities. The link can be identified by searching the plurality of entity profiles to locate common data elements. For example, the first data source may provide information regarding a fraudulent transaction (i.e., fraud data) that was committed by John Doe, and an entity profile corresponding to John Doe and the fraud data can be created. The data elements provided by the second data source may include the name John Doe and a street address where John Doe lives. The system can search the plurality of entity profiles to identify the name John Doe as a link between the information provided from the first data source and the information provided from the second data source. In an exemplary embodiment, the system may use an additional verification procedure to ensure that the John Doe living at the street address is the same John Doe from the entity profile.
If a link exists between the entity profile and the second data element(s) received from the second data source, the second data element(s) are correlated with the entity profile in an operation 140. As a result, the updated entity profile is more likely to flag a financial transaction involving John Doe. If a link does not exist between the entity profile, the second data element(s) are stored for future evaluation in an operation 135. The future evaluation can be conducted when additional entity profiles are created by the system to ensure that the entity profiles include a maximal number of data elements associated with the entity. Alternatively, the second data element(s) may be discarded if a link is not found. In an exemplary embodiment, the first data element can be provided with the second data element, and the first data element can be used to link the second data element to the entity profile.
In an exemplary embodiment, the entity profile may include a plurality of fraudulent acts associated with the entity. Fraud data regarding the plurality of fraudulent acts may be received from one or more data sources. In an operation 145, the system can assign an entity profile risk assessment to the entity profile. The entity profile risk assessment can be based at least in part on the number of fraudulent transactions associated with the entity profile and the risk values assigned to each of the fraudulent transactions. The entity profile risk assessment may also be based on the reliability of the data elements associated with the profile entity, the reliability of the data sources which provided the data elements, and/or the likelihood that the data elements are actually associated with the entity. As an example, a first entity profile may have a first fraudulent act, a second fraudulent act, and three data elements associated therewith. The entity profile risk assessment of the first entity profile can be based on a risk value of the first fraudulent act, a risk value of the second fraudulent act, the reliability of the data source(s) which provided the information regarding the fraudulent acts, the number of data elements associated with the entity profile, the likelihood that the data elements are correctly associated with the entity profile, and/or the reliability of the data source(s) which provided the data elements. In an exemplary embodiment, the entity profile risk assessment can be used to help determine whether a given request for payment to a payee should be granted or denied. In alternative embodiments, any other method(s) may be used to assign the entity profile risk assessment to the entity profile.
In one embodiment, the entity profile risk assessment may be determined in real time upon receipt of a request for payment to a payee. In such an embodiment, the entity profile risk assessment can be determined as part of a transaction risk assessment which is used to ultimately determine whether a request for payment should be granted. In addition to the factors described above, the transaction risk assessment can be based on payee identifiers which are associated with the payee. For example, the transaction risk assessment can be based on the number of payee identifiers which match data elements from the entity profile. A larger number of matching pairs can imply a higher probability that the payee corresponds to the entity from the entity profile. The transaction risk assessment can also be based on the degree of similarity between the payee identifiers and the data elements from the entity profile. For example, the system can recognize that the names ‘Bob’ and ‘Robert’ have a high degree of similarity, even though they have a different spelling. The degree of commonality of the payee identifier and/or the data element it is compared to can also be a factor upon which the transaction risk assessment is based. For example, a payee identifier name of ‘John Smith’ which matches the name ‘John Smith’ in an entity profile may be accorded less weight than a match of the name ‘Jebediah Crunch.’
FIG. 2 is a flow diagram illustrating operations performed by the payee fraud reduction system in response to a request for payment in accordance with an exemplary embodiment. In alternative embodiments, fewer, additional, or different operations may be performed. In an operation 200, a request for payment or transaction risk assessment request is received by the system. In an exemplary embodiment, the request for payment can be initiated by a payor through a channel of a financial institution. For example, the request for payment may be a request by the payor to transfer owed funds to a payee. Alternatively, the request for payment may be initiated by the payee (i.e., the payee may attempt to cash a check or otherwise receive funds from the payor), or by any other institution designated to receive requests for payment and forward them to the system. The channel of the financial institution can be any payment origination channel through which funds can be transferred to a payee. For example, the channel may be a telephone banking channel, an Internet (or network) banking channel, a wire transfer channel, an account-to-account transfer channel, a bill pay channel, a money order transaction channel, an automated clearinghouse (ACH) channel, a paper check transaction channel, an inter-bank transfer channel, a person-to-person channel, a mobile payment channel, etc.
In one embodiment, the system may be incorporated within the financial institution such that the request for payment is automatically received by the system upon receipt by the financial institution. Alternatively, the system may be maintained by a separate entity which is distinct from the financial institution. In such an embodiment, the system can provide fraud detection and payment recommendation services to a plurality of financial or other institutions (i.e., a consortium), and/or receive fraud data and data elements from members of the consortium. Alternatively, the system may receive a transaction risk assessment request based on a request for payment. The transaction risk assessment request can include one or more payee identifiers associated with the request for payment. In an exemplary embodiment, the transaction risk assessment request can be provided by a financial or other institution which receives the request for payment. Alternatively, any other requester, including the payee, can provide the transaction risk assessment request.
In an operation 205, one or more payee identifiers associated with the request for payment are identified. In an exemplary embodiment, the potential categories of payee identifiers can correspond to the potential categories of data elements as described with reference to FIG. 1. For example, the name of the payee can be a first payee identifier which potentially corresponds to a name data element, an address of the payee can be a second payee identifier which potentially corresponds to an address data element, a telephone number of the payee can be a third payee identifier which potentially corresponds to a telephone number data element, and so on. Alternatively, the payee identifier can be any other type of information which can be used to associate a payee with an entity profile. The payee identifier(s) can be provided by the payee and/or the payor depending on the type of financial transaction and the banking channel through which the financial transaction is conducted.
In an operation 210, the system determines whether there is a link between the identified payee identifier(s) and any of the entity profiles accessible to the system. The process for determining whether a link exists can be similar to the process for identifying links between data elements and entity profiles as described above with reference to FIG. 1. The plurality of entity profiles can be searched to determine whether the identified payee identifier(s) match any data elements associated with any of the entity profiles. If a plurality of payee identifiers have been received, the system can search for each of the payee identifiers within the entity profiles. If the system does not find a match between a payee identifier and a data element associated with an entity profile, the system can grant the request for payment in an operation 215. Alternatively, the system may just notify the requestor that no matches were found. In an exemplary embodiment, if one or more links are found, a confidence value can be determined. The confidence value, which may be a percentage, can be the likelihood that a payee associated with the request for payment is the entity associated with an entity profile. The confidence value can be based on the number of payee identifiers which match an entity profile and/or the quality of the matches.
If a link between the payee identifier and one or more entity profiles is identified, the system generates a transaction risk assessment in an operation 212. In an exemplary embodiment, a transaction risk assessment can be generated for each entity profile for which a link was identified in operation 210. The transaction risk assessment(s) can be generated in real time, and can be based on any risk value(s) and/or an entity profile risk assessment associated with the entity profile(s) as described with reference to FIG. 1. The transaction risk assessment(s) can be also based on the confidence value (i.e., the likelihood that the payee actually corresponds to the entity associated with the entity profile). If multiple entity profiles are identified as being linked to a payee, the system can generate an individual transaction risk assessment for each identified entity profile. In one embodiment, the plurality of individual transaction risk assessments can be averaged to determine the transaction risk assessment. Alternatively, if the confidence value is the same (or similar) for a plurality of entity profiles, the entity profile risk assessments of the plurality of entity profiles may be averaged, and the average multiplied by the confidence value (or average confidence value) to obtain the transaction risk assessment. Alternatively, the transaction risk assessment may be the highest individual risk assessment, the lowest individual risk assessment, a median individual risk assessment, or based on any other mathematical manipulation(s) of the plurality of individual risk assessments.
As a numerical example, the entity profile risk assessment may be expressed as a value between 0 (low risk) and 100 (high risk). A particular entity profile may have an entity profile risk assessment of 65, and a payee associated with a request for payment or transaction risk assessment request may match the particular entity profile with a confidence value of 83%. The transaction risk assessment, which may be obtained by multiplying the entity profile risk assessment and the confidence value, can be 53.95. In alternative embodiments, the entity profile risk assessment may be expressed in any other terms. In other alternative embodiments, any other mathematical manipulation(s) may be used to obtain the transaction risk assessment. The transaction risk assessment may also be based on any other values or factors. In one embodiment, the transaction risk assessment may be a predetermined value which does not consider the likelihood that the payee identifiers correspond to the entity profile.
The system determines if the transaction risk assessment(s) satisfy a risk threshold in an operation 220. The risk threshold can be determined by the system, one or more financial institutions, a governmental entity, or any other source. In one embodiment in which the system serves a plurality of financial institutions, different financial institutions may have different risk thresholds. If the risk threshold is satisfied for all of the entity profiles for which a link was identified, the system grants the request for payment in operation 215. Alternatively, the system may just notify the bank that the risk threshold is satisfied for all identified entity profiles. If the risk threshold is not satisfied for any of the identified entity profiles, the system denies the request for payment in an operation 225. In an alternative embodiment, the system may provide the transaction risk assessment to a financial institution or other system user, and the financial institution (or other system user) can make the decision of whether to grant or deny the request for payment. In one embodiment, the transaction risk assessment may be used as a factor within the system user's larger fraud reduction system, and the larger fraud reduction system can make the decision regarding whether to grant or deny the request for payment. It is important to understand that the system described herein is not limited to use by financial institutions. The system can also be used by department stores, decoupled debit card providers, and/or any other businesses or individuals that initiate payments. In an exemplary embodiment, any of the operations performed by the system can be embodied as instructions stored in a computer-readable medium. Upon execution of the instructions by a processor, the instructions can cause the processor to perform the above-described operations. In one embodiment, the system may provide an audit report which identifies a reason for the denial of the request for payment or a reason for the unfavorable transaction risk assessment. The audit report may identify the fraudulent act(s) of the payee, the data source(s) which provided fraud data corresponding the fraudulent act(s), and/or any other information relevant to the transaction risk assessment.
FIG. 3 is a block diagram illustrating a payee fraud reduction system in accordance with an exemplary embodiment. A first data source 300, a second data source 305, and a third data source 310 can provide data elements and/or fraud data to a profile generator 315 of the payee fraud reduction system (system). The data elements and/or fraud data can also be provided to a negative payee storage module 320. Profile generator 315 can receive data element(s) and fraud data corresponding to a given entity. Profile generator 315 can use the data element(s) and fraud data to create an entity profile which can be stored in negative payee storage module 320. Profile generator 315 can also assign a risk value to individual fraudulent transactions and/or assign an entity profile risk assessment to the entity profile. In addition, profile generator 315 can identify links between existing entity profiles and additional data elements which are received from first data source 300, second data source 305, and third data source 310. If links are identified, profile generator 315 can update the entity profiles accordingly.
Payment module 325 can receive requests for payment from a financial institution 330. Alternatively, the requests for payment may be received from an entity, such as a governmental entity or a corporation, which is not a financial institution. Financial institution 330 can receive the request for payment from a payment requester 335. Payment requester 335 may be a payee or a payor depending on the transaction. In an exemplary embodiment, the request for payment can be a request for a funds transfer from the payor to the payee. Payment module 325 can identify payee identifier(s) associated with the payee of the request for payment, and determine whether the identified payee identifier(s) match any data elements associated with an entity profile. If no matches (or links) are identified, payment module 325 can grant the payment request or simply inform financial institution 330, depending on the embodiment. If there are any entity profiles with a data element which matches one or more payee identifiers of the payee, payment module 325 can generate a transaction risk assessment for each of the identified entity profiles. Depending on the embodiment, payment module 325 may also be used to generate risk values and/or entity profile risk assessments for profile entities stored in negative payee storage module 320. Payment module 325 can compare the transaction risk assessment with a risk threshold to determine whether the risk threshold is satisfied. If the risk threshold is satisfied, payment module 325 can grant the request for payment or inform financial institution 330 that the request for payment has been cleared. If the risk threshold is not satisfied, payment module 325 can deny the request for payment or inform financial institution 330 that there is a problem. Financial institution 330 can inform payment requester 335 whether the request for payment is allowed or denied. Alternatively, financial institution 330 can receive the transaction risk assessment and make a determination whether to grant or deny the request for payment based at least in part on the transaction risk assessment.
In one embodiment, the system of FIG. 3 can also include a reviewer for reviewing denied requests for payment. Incorrect denials of payment can cause problems for customers of financial institution 330 (i.e., a deadline for payment of a bill may be missed), and can result in a negative reputation for financial institution 330. The reviewer can be an individual who manually reviews the denied requests and makes a final decision based on additional research and/or previous knowledge. For example, a denial of payment may be based on a street address which was associated with a fraudulent act of an entity. The reviewer may be able to determine that the entity which committed the fraudulent act has moved and that the new resident (i.e., the payee of the current request for payment) has no association with fraud. In such an instance, the reviewer can also ensure that the entity profile stored in negative payee storage module 320 is updated to reflect the change of address. In an alternative embodiment, the payor may be notified of a potential fraudulent payee and asked whether he/she/it would like to proceed with the transaction.
As an example using the system of FIG. 3, the second data source 305 can be a fraud information firm dedicated to collecting information regarding fraudulent transactions, and the third data source 310 can be an internal data source within financial institution 330. The fraud information firm can provide profile generator 315 with information regarding a fraudulent act that was associated with a particular Internet protocol (IP) address. The internal data source, which can be a customer database of financial institution 330, can provide information regarding a telephone number and a street address associated with the IP address. Profile generator 315 can use the fraudulent act and the IP address to generate an entity profile surrounding the fraudulent act. Profile generator 315 can use the IP address to link the street address to the entity profile. Profile generator 315 can also use the street address to link the telephone number to the entity profile. Profile generator 315 can also use fraud factors associated with the fraudulent act to generate a risk value for the fraudulent act and/or an entity profile risk assessment for the entity profile. The entity profile can be stored in negative payee storage module 320.
Continuing the example from above, payment requester 335 can be a payor who uses a debit card to pay a payee for an online purchase of goods. The request for payment can result from the debit card transaction. Financial institution 330 can be a bank which manages the financial accounts of the payor and receives the request for payment. The request for payment to the payee can include at least a financial account number of the payee, a company name of the payee, a street address of the payee, and a telephone number of the payee. The bank can submit the request for payment, including the payee identifiers (i.e., the financial account number, company name, street address, and telephone number of the payee) to payment module 325.
Payment module 325 can perform a search of negative payee storage module 320 to determine whether any of the payee identifiers match any data elements stored within negative payee storage module 320. Payment module 325 can determine that the street address of the payee matches the street address contained in the above-described entity profile. Payment module 325 can generate a confidence score based on the likelihood that the payee is the entity associated with the entity profile. Based at least in part on the confidence score and the entity profile risk assessment of the entity profile, payment module 320 can generate a transaction risk assessment for the request for payment. If the transaction risk assessment does not satisfy a risk threshold used by the bank, payment module 320 can deny the request for payment. In one embodiment, a reviewer can review the denial for request for payment to help ensure that the denial is not in error. If the transaction risk assessment for the entity profile satisfies the risk threshold, the request for payment can be granted.
One or more flow diagrams have been used to describe exemplary embodiments. The use of flow diagrams is not meant to be limiting with respect to the order of operations performed. The foregoing description of exemplary embodiments has been presented for purposes of illustration and of description. It is not intended to be exhaustive or limiting with respect to the precise form disclosed, and modifications and variations are possible in light of the above teachings or may be acquired from practice of the disclosed embodiments. It is intended that the scope of the invention be defined by the claims appended hereto and their equivalents.

Claims (19)

1. A method for reducing fraudulent transactions, the method comprising the computer implemented steps of:
receiving fraud data from a first data source, wherein the fraud data is related to a fraudulent transaction of an entity;
receiving a first data element corresponding to the entity from the first data source;
correlating the first data element with the fraudulent transaction of the entity to form an entity profile;
receiving the first data element and a second data element corresponding to the entity from a second data source;
correlating the second data element with the entity profile based on the first data element;
generating an entity profile risk assessment associated with the entity profile;
receiving a transaction risk assessment request based on a request for payment to a payee, wherein the transaction risk assessment request includes a payee identifier;
comparing the payee identifier to the entity profile to generate a confidence score; and
generating a transaction risk assessment based at least in part on the entity profile risk assessment and at least in part on the confidence score.
2. The method of claim 1, wherein the first data source comprises at least one of a financial institution, a government institution, a corporation, a consortium member, or a private institution.
3. The method of claim 1, further comprising storing the entity profile in a negative payee storage module.
4. The method of claim 1, wherein the first data element comprises at least one of a name of the entity, an alias of the entity, a postal address of the entity, a delivery address of the entity, an entity type, a telephone number of the entity, a fax number of the entity, a driver's license number of the entity, a state identification number of the entity, an account routing number of the entity, an account number of the entity, a social security number of the entity, a tax identification number of the entity, an e-mail address of the entity, a web domain name of the entity, a credit card number of the entity, an Internet protocol (IP) address of the entity, or a relationship of the entity.
5. The method of claim 1, further comprising granting the request for payment only if the transaction risk assessment satisfies a risk assessment threshold.
6. The method of claim 1, wherein the request for payment comprises at least one of a money order request, a wire transfer request, or an automated clearinghouse request.
7. The method of claim 1, further comprising providing an audit report, wherein the audit report identifies a reason for a denial of the request for payment.
8. The method of claim 7, wherein the audit report further identifies the first data source.
9. The method of claim 1, wherein the transaction risk assessment request is received from a financial institution.
10. The method of claim 1, wherein the entity profile risk assessment is based at least in part on the fraudulent transaction.
11. The method of claim 10, further comprising receiving one or more fraud factors associated with the fraudulent act, wherein the entity profile risk assessment is based at least in part on the one or more fraud factors.
12. A computer-readable medium having computer-readable instructions stored thereon that, upon execution by a processor, cause the processor to:
receive fraud data from a first data source, wherein the fraud data is related to a fraudulent transaction of an entity;
receive a first data element corresponding to the entity from the first data source;
correlate the first data element with the fraudulent transaction to form an entity profile of the entity;
receive the first data element and a second data element corresponding to the entity from a second data source;
correlate the second data element with the entity profile based on the first data element;
generate an entity profile risk assessment associated with the entity profile;
receive a transaction risk assessment request based on a request for payment to a payee, wherein the transaction risk assessment request includes a payee identifier;
generate a confidence score based at least in part on the payee identifier; and
generate a transaction risk assessment based at least in part on the entity profile risk assessment and at least in part on the confidence score.
13. The computer-readable medium of claim 12, wherein the processor is further caused to determine whether to grant the request for payment based on the transaction risk assessment.
14. The computer-readable medium of claim 13, wherein determining whether to grant the request for payment comprises comparing the transaction risk assessment to a risk assessment threshold.
15. The computer-readable medium of claim 12, wherein the payee identifier is received from a requestor that provided the request for payment.
16. The computer-readable medium of claim 12, wherein the processor is further caused to store the entity profile in a negative payee storage module, wherein the negative payee storage module comprises a plurality of entity profiles.
17. The computer-readable medium of claim 12, wherein the transaction risk assessment request is received from the payee.
18. A system for reducing fraudulent transactions, the system comprising:
a profile generator configured to
receive fraud data from a first data source, wherein the fraud data is related to a fraudulent transaction of an entity;
receive a first data element corresponding to the entity from the first data source;
generate an entity profile, wherein the entity profile comprises an association between the fraud data and the first data element;
receive the first data element and a second data element corresponding to the entity from a second data source;
correlate the second data element with the entity profile based on the first data element; and
generate an entity profile risk assessment for the entity profile, wherein the entity profile risk assessment is based at least in part on the fraud data; and
a payment module configured to
receive a transaction risk assessment request based on a request for payment, wherein the request for payment comprises a monetary request to a payee, and further wherein the transaction risk assessment request includes a payee identifier corresponding to the payee;
compare the payee identifier to the entity profile to generate a confidence score; and
generate a transaction risk assessment based at least in part on the entity profile risk assessment and at least in part on the confidence score.
19. The system of claim 18, further comprising a negative payee storage module configured to receive and store the entity profile.
US11/941,636 2007-11-16 2007-11-16 Method, system, and computer-readable medium for reducing payee fraud Active US7440915B1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US11/941,636 US7440915B1 (en) 2007-11-16 2007-11-16 Method, system, and computer-readable medium for reducing payee fraud

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US11/941,636 US7440915B1 (en) 2007-11-16 2007-11-16 Method, system, and computer-readable medium for reducing payee fraud

Publications (1)

Publication Number Publication Date
US7440915B1 true US7440915B1 (en) 2008-10-21

Family

ID=39855683

Family Applications (1)

Application Number Title Priority Date Filing Date
US11/941,636 Active US7440915B1 (en) 2007-11-16 2007-11-16 Method, system, and computer-readable medium for reducing payee fraud

Country Status (1)

Country Link
US (1) US7440915B1 (en)

Cited By (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060218088A1 (en) * 2005-03-24 2006-09-28 Flora John R Intelligent auto-fill transaction data
US20060218087A1 (en) * 2005-03-24 2006-09-28 Zimmerman Jeffrey P Automated aggregation and comparison of individual spending relative to population of similar users
US20060218086A1 (en) * 2005-03-24 2006-09-28 Heather Campbell Payee aliasing
US20060224558A1 (en) * 2005-03-24 2006-10-05 Flora John R Associating multiple categories with single payee or payor in financial software application
US20070168267A1 (en) * 2006-01-13 2007-07-19 Zimmerman Jeffey P Automated aggregation and comparison of business spending relative to similar businesses
US20110047076A1 (en) * 2009-08-24 2011-02-24 Mark Carlson Alias reputation interaction system
US20120284175A1 (en) * 2011-05-03 2012-11-08 Panther Payments, LLC Method and system for facilitating person-to-person payments
US20130185293A1 (en) * 2011-12-09 2013-07-18 Robert J. Boback System for forensic analysis of search terms
US8660957B2 (en) 2006-01-30 2014-02-25 Solutran Control features in a system and method for processing checks and check transactions
US20140214669A1 (en) * 2013-01-29 2014-07-31 Gravic, Inc. Methods for Reducing the Merchant Chargeback Notification Time
US8799122B1 (en) * 2008-03-31 2014-08-05 Intuit Inc. Method and system for user contributed aggregated fraud identification
WO2014145566A1 (en) * 2013-03-15 2014-09-18 Gibson Jeffrey S Financial account protection method utilizing a variable assigning request string generator and receiver algorithm
US20140379457A1 (en) * 2009-11-06 2014-12-25 Edatanetworks Inc. Program, system and method for linking community programs and merchants in a marketing program
AU2012230299B2 (en) * 2011-03-23 2016-04-14 Detica Patent Limited An automated fraud detection method and system
US20160110719A1 (en) * 2008-03-03 2016-04-21 Jpmorgan Chase Bank, N.A. Authentication and Interaction Tracking System and Method
US20180308099A1 (en) * 2017-04-19 2018-10-25 Bank Of America Corporation Fraud Detection Tool
US10157140B2 (en) 2017-03-28 2018-12-18 Bank Of America Corporation Self-learning cache repair tool
US10320662B1 (en) 2017-11-17 2019-06-11 Bank Of America Corporation Centralized resource routing and distribution
US10530780B2 (en) 2017-10-11 2020-01-07 Bank Of America Corporation Entity validation for resource distribution location
US10579440B2 (en) 2017-11-07 2020-03-03 Bank Of America Corporation Virtual resource control and distribution
US10817356B2 (en) 2017-10-11 2020-10-27 Bank Of America Corporation Entity resource distribution channel manipulation
US20200356997A1 (en) * 2016-12-23 2020-11-12 Early Warning Services, Llc System and method using multiple profiles and scores for assessing financial transaction risk
US10963857B2 (en) 2012-11-27 2021-03-30 Verizon Media Inc. Systems and methods for processing electronic transactions based on consumer characteristics
US11042858B1 (en) * 2016-12-23 2021-06-22 Wells Fargo Bank, N.A. Assessing validity of mail item
US11416864B2 (en) * 2018-09-11 2022-08-16 Visa International Service Association System, method, and computer program product for fraud management with a shared hash map
US11954661B1 (en) 2021-05-18 2024-04-09 Wells Fargo Bank, N.A. Assessing validity of mail item

Citations (34)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5679940A (en) * 1994-12-02 1997-10-21 Telecheck International, Inc. Transaction system with on/off line risk assessment
US5956700A (en) 1994-06-03 1999-09-21 Midwest Payment Systems System and method for paying bills and other obligations including selective payor and payee controls
US6181814B1 (en) 1996-01-18 2001-01-30 Merrill Lynch & Co. Inc. Check fraud detection techniques using encrypted payee information
US6330546B1 (en) 1992-09-08 2001-12-11 Hnc Software, Inc. Risk determination and management using predictive modeling and transaction profiles for individual transacting entities
US20020052841A1 (en) 2000-10-27 2002-05-02 Guthrie Paul D. Electronic payment system
US20020069158A1 (en) 2000-12-01 2002-06-06 Larkin Cameron J. Method and system for providing a secured multi-purpose electronic account
US6418436B1 (en) 1999-12-20 2002-07-09 First Data Corporation Scoring methodology for purchasing card fraud detection
US6535728B1 (en) 1998-11-18 2003-03-18 Lightbridge, Inc. Event manager for use in fraud detection
US20030130919A1 (en) 2001-11-20 2003-07-10 Randy Templeton Systems and methods for selectively accessing financial account information
US20030140004A1 (en) 1999-05-03 2003-07-24 Chase Manhattan Bank Method and system for processing internet payments using the electronic funds transfer network
US20030172030A1 (en) 2002-03-06 2003-09-11 Parascript, Llc Payee match positive pay banking
US20030187786A1 (en) 2002-03-26 2003-10-02 Amy Swift Merchant transponder systems using electronic check processing
US20030204475A1 (en) 2002-04-29 2003-10-30 Nicholas Cuda Method for the prevention of the unauthorized payments of funds
US20030204457A1 (en) 2002-04-26 2003-10-30 Arias Luis A. Payee account payment system
US20030212617A1 (en) 2002-05-13 2003-11-13 Stone James S. Accounts payable process
US20030213841A1 (en) 2002-05-14 2003-11-20 Josephson Stanley M. Method for verifying and authenticating initially named payee of negotiable instruments
US20030217003A1 (en) 2002-05-14 2003-11-20 Primary Payment Systems, Inc. Database for check risk decisions populated with check activity data from banks of first deposit
US20030225729A1 (en) 2002-05-31 2003-12-04 American Express Travel Related Services Company, Inc. System and method for facilitating information collection, storage, and distribution
US20040019605A1 (en) 2002-07-26 2004-01-29 Blake Keown Techinque for accessing an electronic payee database
US20040030649A1 (en) 2002-05-06 2004-02-12 Chris Nelson System and method of application processing
US20040030644A1 (en) 2001-12-14 2004-02-12 Shaper Stephen J. Systems for facilitating card processing systems/improved risk control
US6714918B2 (en) 2000-03-24 2004-03-30 Access Business Group International Llc System and method for detecting fraudulent transactions
US20040078328A1 (en) 2002-02-07 2004-04-22 Talbert Vincent W. Method and system for completing a transaction between a customer and a merchant
US20040153663A1 (en) 2002-11-01 2004-08-05 Clark Robert T. System, method and computer program product for assessing risk of identity theft
US20040210520A1 (en) 2003-04-02 2004-10-21 Fitzgerald Daleen R. Bill payment payee information management system and method
US20040236688A1 (en) 2000-10-30 2004-11-25 Bozeman William O. Universal positive pay database method, system, and computer useable medium
US6957770B1 (en) 2002-05-10 2005-10-25 Biopay, Llc System and method for biometric authorization for check cashing
US20060101508A1 (en) 2004-06-09 2006-05-11 Taylor John M Identity verification system
US20060187698A1 (en) 2005-02-08 2006-08-24 Schmidt Igor J System and method for dynamic checking
US7107243B1 (en) 1998-08-10 2006-09-12 Citibank, N.A. System and method for automated bill payment service
US20060212407A1 (en) 2005-03-17 2006-09-21 Lyon Dennis B User authentication and secure transaction system
US7139731B1 (en) 1999-06-30 2006-11-21 Alvin Robert S Multi-level fraud check with dynamic feedback for internet business transaction processor
US20070138257A1 (en) 2005-12-20 2007-06-21 Bruce Dragt Systems and methods for performing a simplified risk assessment
US7246740B2 (en) 2003-04-03 2007-07-24 First Data Corporation Suspicious persons database

Patent Citations (34)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6330546B1 (en) 1992-09-08 2001-12-11 Hnc Software, Inc. Risk determination and management using predictive modeling and transaction profiles for individual transacting entities
US5956700A (en) 1994-06-03 1999-09-21 Midwest Payment Systems System and method for paying bills and other obligations including selective payor and payee controls
US5679940A (en) * 1994-12-02 1997-10-21 Telecheck International, Inc. Transaction system with on/off line risk assessment
US6181814B1 (en) 1996-01-18 2001-01-30 Merrill Lynch & Co. Inc. Check fraud detection techniques using encrypted payee information
US7107243B1 (en) 1998-08-10 2006-09-12 Citibank, N.A. System and method for automated bill payment service
US6535728B1 (en) 1998-11-18 2003-03-18 Lightbridge, Inc. Event manager for use in fraud detection
US20030140004A1 (en) 1999-05-03 2003-07-24 Chase Manhattan Bank Method and system for processing internet payments using the electronic funds transfer network
US7139731B1 (en) 1999-06-30 2006-11-21 Alvin Robert S Multi-level fraud check with dynamic feedback for internet business transaction processor
US6418436B1 (en) 1999-12-20 2002-07-09 First Data Corporation Scoring methodology for purchasing card fraud detection
US6714918B2 (en) 2000-03-24 2004-03-30 Access Business Group International Llc System and method for detecting fraudulent transactions
US20020052841A1 (en) 2000-10-27 2002-05-02 Guthrie Paul D. Electronic payment system
US20040236688A1 (en) 2000-10-30 2004-11-25 Bozeman William O. Universal positive pay database method, system, and computer useable medium
US20020069158A1 (en) 2000-12-01 2002-06-06 Larkin Cameron J. Method and system for providing a secured multi-purpose electronic account
US20030130919A1 (en) 2001-11-20 2003-07-10 Randy Templeton Systems and methods for selectively accessing financial account information
US20040030644A1 (en) 2001-12-14 2004-02-12 Shaper Stephen J. Systems for facilitating card processing systems/improved risk control
US20040078328A1 (en) 2002-02-07 2004-04-22 Talbert Vincent W. Method and system for completing a transaction between a customer and a merchant
US20030172030A1 (en) 2002-03-06 2003-09-11 Parascript, Llc Payee match positive pay banking
US20030187786A1 (en) 2002-03-26 2003-10-02 Amy Swift Merchant transponder systems using electronic check processing
US20030204457A1 (en) 2002-04-26 2003-10-30 Arias Luis A. Payee account payment system
US20030204475A1 (en) 2002-04-29 2003-10-30 Nicholas Cuda Method for the prevention of the unauthorized payments of funds
US20040030649A1 (en) 2002-05-06 2004-02-12 Chris Nelson System and method of application processing
US6957770B1 (en) 2002-05-10 2005-10-25 Biopay, Llc System and method for biometric authorization for check cashing
US20030212617A1 (en) 2002-05-13 2003-11-13 Stone James S. Accounts payable process
US20030217003A1 (en) 2002-05-14 2003-11-20 Primary Payment Systems, Inc. Database for check risk decisions populated with check activity data from banks of first deposit
US20030213841A1 (en) 2002-05-14 2003-11-20 Josephson Stanley M. Method for verifying and authenticating initially named payee of negotiable instruments
US20030225729A1 (en) 2002-05-31 2003-12-04 American Express Travel Related Services Company, Inc. System and method for facilitating information collection, storage, and distribution
US20040019605A1 (en) 2002-07-26 2004-01-29 Blake Keown Techinque for accessing an electronic payee database
US20040153663A1 (en) 2002-11-01 2004-08-05 Clark Robert T. System, method and computer program product for assessing risk of identity theft
US20040210520A1 (en) 2003-04-02 2004-10-21 Fitzgerald Daleen R. Bill payment payee information management system and method
US7246740B2 (en) 2003-04-03 2007-07-24 First Data Corporation Suspicious persons database
US20060101508A1 (en) 2004-06-09 2006-05-11 Taylor John M Identity verification system
US20060187698A1 (en) 2005-02-08 2006-08-24 Schmidt Igor J System and method for dynamic checking
US20060212407A1 (en) 2005-03-17 2006-09-21 Lyon Dennis B User authentication and secure transaction system
US20070138257A1 (en) 2005-12-20 2007-06-21 Bruce Dragt Systems and methods for performing a simplified risk assessment

Non-Patent Citations (17)

* Cited by examiner, † Cited by third party
Title
"New Fraud database to thwart rising fraud," Computer Fraud & Security, vol. 2002, No. 10, Oct. 2002, pp. 3.
Affirmative Technologies website, http://www.affirmativeusa.com/check<SUB>-</SUB>verification<SUB>-</SUB>negitiva<SUB>-</SUB>database.htm, "Check Verification-Negative Database," printed Nov. 15, 2007.
BAI Online Website, http://www.bai.org/bankingstrategies/2006-may-june/PaymentsStrategies/Checks/index.asp, Hoffman, "Retailers' Role in the Demise of the Check," Published May 2006, printed Nov. 13, 2007.
BAI Online website, http://www.bai.org/BANKINGSTRATEGIES/2006-MAY-JUNE/PaymentsStrategies/Smallbusiness/index.asp?WT.mc<SUB>-</SUB>id=BS<SUB>-</SUB>SEPTOCT06<SUB>-</SUB>MAYJUNE06<SUB>-</SUB>PSSMALLBUSINESS, Nagarkatte, "The Small Business Customer is Ready to Switch-for Payment Products," available May 2006, printed Sep. 15, 2007.
Bank of America website, http://corp.bankofamerica.com/publicpdf/products/wcm<SUB>-</SUB>ar<SUB>-</SUB>fraud<SUB>-</SUB>check.pdf "Combating Fraud on Corporate Checking Accounts, a Bank of America White Paper," available Feb. 2004, printed Nov. 15, 2007.
BioPay website, http://www.biopay.com/press-release-102303.asp, BioPay and Answers, Etc. Partner to Stop Check Fraud Nationwide, Oct. 23, 2003, printed Nov. 15, 2007.
Chapman, et al., "Controlling Financial Services Fraud", Australian Institution of Criminology Trends & Issues, No. 189, Feb. 2001.
CheckFree Corp. website, http://www.checkfreecorp.com/cda/corp/L5.jsp?layoutId=50020&contentId=46503&menuId=50059&pId=50021, "CheckFree FraudNet: Shared Intelligence for Increased Fraud Prevention," printed Nov. 15, 2007.
e-check Solutions, Inc. website, http://www.echecksolutions.com/NCNVerify.htm, "Negative Database Check Verification," printed Sep. 15, 2007.
e-Solutions website, http://www.esolutionsoffice.com/checkverification/ "Check Verification, Verify Checks Before Accepting Them!", printed Sep. 15, 2007.
FinCrime.com website, https://secure.fincrime.com/about<SUB>-</SUB>fcn.cfm, "Frequently Asked Questions," printed Nov. 15, 2007.
First Data Corporation website, http://firstdata.com/product<SUB>-</SUB>solutions/payment<SUB>-</SUB>solutions/telecheck/eca<SUB>-</SUB>verification.htm ,"TeleCheck Electronic Check Acceptance(R) (ECA(R)) verification," printed Sep. 15, 2007.
Guerin-Calvert et al., "Merchant Benefits and Public Policy towards Interchange: An Economic Assessment," Review of Network Economics, vol. 4, Issue 4, Dec. 2005, pp. 384-414.
Instamerchant.com website, http://www.instamerchant.com/avoid-credicard-fraud.html, "Stopping Fraud When Accepting Credit Cards Online," printed Nov. 13, 2007.
Instamerchant.com website, http://www.instamerchant.com/avoid-creditcard-fraud.html, "Stopping Fraud When Accepting Credit Cards Online," printed Sep. 15, 2007.
Mitek Systems, Inc., http://mail.miteksystems.com/pdf/FPS%20SDK%200206.pdf, "Image Based Forgery Detection You Need to Fight Check Fraud," printed Nov. 16, 2007.
PR Newswire website, http://www.prnewswire.com/cgi-bin/stories.pl?ACCT=104&STORY=/www/story/02-10-2004/0002106277&EDATE=, "Mitek Introduces PADsafe Toolkit to Detect Preauthorized Draft Fraud," printed Nov. 15, 2007.

Cited By (40)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060218088A1 (en) * 2005-03-24 2006-09-28 Flora John R Intelligent auto-fill transaction data
US20060218087A1 (en) * 2005-03-24 2006-09-28 Zimmerman Jeffrey P Automated aggregation and comparison of individual spending relative to population of similar users
US20060218086A1 (en) * 2005-03-24 2006-09-28 Heather Campbell Payee aliasing
US20060224558A1 (en) * 2005-03-24 2006-10-05 Flora John R Associating multiple categories with single payee or payor in financial software application
US8177121B2 (en) 2006-01-13 2012-05-15 Intuit Inc. Automated aggregation and comparison of business spending relative to similar businesses
US20070168267A1 (en) * 2006-01-13 2007-07-19 Zimmerman Jeffey P Automated aggregation and comparison of business spending relative to similar businesses
US8660957B2 (en) 2006-01-30 2014-02-25 Solutran Control features in a system and method for processing checks and check transactions
US20160110719A1 (en) * 2008-03-03 2016-04-21 Jpmorgan Chase Bank, N.A. Authentication and Interaction Tracking System and Method
US10600055B2 (en) 2008-03-03 2020-03-24 Jpmorgan Chase Bank, N.A. Authentication and interaction tracking system and method
US20170337557A1 (en) * 2008-03-03 2017-11-23 Jpmorgan Chase Bank, N.A. Authentication and Interaction Tracking System and Method
US9734501B2 (en) * 2008-03-03 2017-08-15 Jpmorgan Chase Bank, N.A. Authentication and interaction tracking system and method
US8799122B1 (en) * 2008-03-31 2014-08-05 Intuit Inc. Method and system for user contributed aggregated fraud identification
US20110047076A1 (en) * 2009-08-24 2011-02-24 Mark Carlson Alias reputation interaction system
US20140330675A1 (en) * 2009-08-24 2014-11-06 Mark Carlson Alias identity and reputation validation engine
US10902449B2 (en) * 2009-11-06 2021-01-26 Edatanetworks Inc. Program, system and method for linking community programs and merchants in a marketing program
US9230263B2 (en) 2009-11-06 2016-01-05 Edatanetworks Inc. Program, system and method for linking community programs and merchants in a marketing program
US20140379457A1 (en) * 2009-11-06 2014-12-25 Edatanetworks Inc. Program, system and method for linking community programs and merchants in a marketing program
AU2012230299B2 (en) * 2011-03-23 2016-04-14 Detica Patent Limited An automated fraud detection method and system
US20120284175A1 (en) * 2011-05-03 2012-11-08 Panther Payments, LLC Method and system for facilitating person-to-person payments
US20130185293A1 (en) * 2011-12-09 2013-07-18 Robert J. Boback System for forensic analysis of search terms
US9135306B2 (en) * 2011-12-09 2015-09-15 Tiversa Ip, Inc. System for forensic analysis of search terms
US10963857B2 (en) 2012-11-27 2021-03-30 Verizon Media Inc. Systems and methods for processing electronic transactions based on consumer characteristics
US20140214669A1 (en) * 2013-01-29 2014-07-31 Gravic, Inc. Methods for Reducing the Merchant Chargeback Notification Time
US9092778B2 (en) 2013-03-15 2015-07-28 Varsgen, Llc Bank account protection method utilizing a variable assigning request string generator and receiver algorithm
WO2014145566A1 (en) * 2013-03-15 2014-09-18 Gibson Jeffrey S Financial account protection method utilizing a variable assigning request string generator and receiver algorithm
US11042858B1 (en) * 2016-12-23 2021-06-22 Wells Fargo Bank, N.A. Assessing validity of mail item
US20230360053A1 (en) * 2016-12-23 2023-11-09 Early Warning Services, Llc System and method using multiple profiles and scores for assessing financial transaction risk
US11741473B2 (en) * 2016-12-23 2023-08-29 Early Warning Services, Llc System and method using multiple profiles and scores for assessing financial transaction risk
US20200356997A1 (en) * 2016-12-23 2020-11-12 Early Warning Services, Llc System and method using multiple profiles and scores for assessing financial transaction risk
US10157140B2 (en) 2017-03-28 2018-12-18 Bank Of America Corporation Self-learning cache repair tool
US20180308099A1 (en) * 2017-04-19 2018-10-25 Bank Of America Corporation Fraud Detection Tool
US10530780B2 (en) 2017-10-11 2020-01-07 Bank Of America Corporation Entity validation for resource distribution location
US10817356B2 (en) 2017-10-11 2020-10-27 Bank Of America Corporation Entity resource distribution channel manipulation
US10929196B2 (en) 2017-11-07 2021-02-23 Bank Of America Corporation Virtual resource control and distribution
US10579440B2 (en) 2017-11-07 2020-03-03 Bank Of America Corporation Virtual resource control and distribution
US10320662B1 (en) 2017-11-17 2019-06-11 Bank Of America Corporation Centralized resource routing and distribution
US11416864B2 (en) * 2018-09-11 2022-08-16 Visa International Service Association System, method, and computer program product for fraud management with a shared hash map
US20220327545A1 (en) * 2018-09-11 2022-10-13 Visa International Service Association System, Method, and Computer Program Product for Fraud Management with a Shared Hash Map
US11797998B2 (en) * 2018-09-11 2023-10-24 Visa International Service Association System, method, and computer program product for fraud management with a shared hash map
US11954661B1 (en) 2021-05-18 2024-04-09 Wells Fargo Bank, N.A. Assessing validity of mail item

Similar Documents

Publication Publication Date Title
US7440915B1 (en) Method, system, and computer-readable medium for reducing payee fraud
US11205160B2 (en) Electronic payment and authentication system with debit and identification data verification and electronic check capabilities
US8296232B2 (en) Systems and methods for screening payment transactions
US8170953B1 (en) Systems and method for screening payment transactions
US7882031B2 (en) Anti-crimes financial network
US8732084B2 (en) Identification and risk evaluation
US20060229961A1 (en) Risk evaluation method and system using ACH data
US20100114774A1 (en) Chargeback decisioning system
US20040117316A1 (en) Method for detecting suspicious transactions
US20150339671A1 (en) Dynamic fraud alert system
US20110173122A1 (en) Systems and methods of bank security in online commerce
US20030233319A1 (en) Electronic fund transfer participant risk management clearing
US20100325035A1 (en) Fraud/risk bureau
US20070012757A1 (en) Identity verification switch
US20080270206A1 (en) Method for detecting suspicious transactions
US11037160B1 (en) Systems and methods for preemptive fraud alerts
US20170018029A1 (en) Systems and methods for utilizing a money transfer network to facilitate lending
US11941632B2 (en) Instant funds availability risk assessment and real-time fraud alert system and method
US20130339244A1 (en) Methods and systems for check cashing risk analysis
WO2005076855A2 (en) Account-owner verificaton database
WO2003104938A2 (en) Electronic fund transfer participant risk management clearing

Legal Events

Date Code Title Description
AS Assignment

Owner name: U.S. BANCORP LICENSING, INC., MINNESOTA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:ULRICH, GLEN;REEL/FRAME:020128/0055

Effective date: 20071115

STCF Information on status: patent grant

Free format text: PATENTED CASE

AS Assignment

Owner name: U.S. BANK, NATIONAL ASSOCIATION, MINNESOTA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:U.S. BANCORP LICENSING, INC.;REEL/FRAME:023094/0583

Effective date: 20090805

FPAY Fee payment

Year of fee payment: 4

FPAY Fee payment

Year of fee payment: 8

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 12TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1553); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

Year of fee payment: 12