HK1162734B - Systems and methods for processing transactions with online merchants - Google Patents

Abstract

Various embodiments of the invention provide a more secure financial transaction system for e-commerce sectors that (1) more securely processes payment transactions, (2) helps to protect merchants and banks against fraudulent transactions, money laundering, and underage gambling, (3) helps to limit other abuses in areas of e-commerce that are perceived to pose special risks, such as Internet gaming, travel, and consumer purchasing of electronic goods, and (4) helps to consolidate processes and information associated with such transactions that lead to reduced data storage and/or reduced computer processing capacity. To accomplish the above goals, various embodiments of the financial transaction system (1) establish operating and transaction processing protocols for merchants, Internet payment service providers, acquiring banks, and card schemes and (2) provide automated systems for monitoring and securely processing payment and financial transactions.

Description

System and method for processing transactions with online merchants

Background

Generally, when a customer wishes to use a payment card (credit or debit) with a merchant (on the internet or elsewhere), the customer sends an electronic authorization request to an acquiring bank. The acquiring bank transmits the electronic authorization request to the issuing bank (i.e., the bank or financial institution that issued the payment card to the customer) via a card issuer network (e.g., Visa, MasterCard, american eexpress, or a private card issuer network). The issuing bank verifies that the customer has sufficient credit, does not delinquent payments, and that all information provided (e.g., card number, card verification value number, and card-holder details) is correct. The issuing bank then sends an electronic message authorizing payment to the acquiring bank through the card issuer network, the acquiring bank sends the electronic message to the merchant, and the merchant accepts the authorization message as a credential for future payment by the issuing bank. The actual transfer of funds occurs at a later stage, referred to as the settlement process.

Payment card transactions occurring over the internet or other network involve risks that are unlikely to exist in face-to-face payment transactions because the card-holder and merchant are not typically together at the time the transaction occurs. In addition, some electronic commerce sectors, such as gambling and adult entertainment, raise additional public interest concerns that further emphasize the need for a system that makes payment card transactions secure and deters fraud and other misuse.

Disclosure of Invention

Embodiments of the present invention provide a more secure financial transaction system for the e-commerce department that (1) more securely processes payment transactions, (2) helps to protect merchants and banks from fraudulent transactions, money laundering, and juveniles, (3) helps to limit other abuses in the field of e-commerce that are considered to pose special risks, such as internet games, travel, and customer purchases of electronic merchandise, and (4) helps to enhance the processing and information associated with transactions that may result in reduced data storage and/or computer processing capabilities. To achieve the above objectives, embodiments of the financial transaction system (1) establish operational and transaction processing protocols for merchants, internet payment service providers, acquiring banks, and card organizations, and (2) provide automated systems for monitoring and securely processing payment and financial transactions. Two or more of the embodiments described herein may be combined to provide a system and method that achieves one or more of these objectives.

According to an embodiment of the present invention, a system for processing a transaction with an online merchant is provided that includes a communication interface and a processor executing a service provider module. The service provider module is configured to: (1) receiving, over a network through a communication interface, a request to conduct a transaction between a customer and an online merchant on a website, the request including (a) a first location associated with an address of the customer and (b) an internet protocol address assigned to a computing device associated with the customer; (2) in response to receiving the request, searching one or more databases storing internet protocol addresses of known gateway devices over the network to identify whether the internet protocol addresses belong to the gateway devices; (3) responsive to the internet protocol address not being associated with the gateway apparatus, searching, over the network, for information in one or more IP geolocation databases to identify a second location corresponding to the internet protocol address and associated with the computing device; (4) requesting information from the gateway device to identify a second location associated with the computing device by providing the gateway device with the internet protocol address, a website on which the transaction is conducted, and a time and date of the transaction in response to the internet protocol address being associated with the gateway device; (5) in response to receiving the information identifying the second location, comparing the first location and the second location to a list of locations stored in memory that regulate transactions with the online merchant; (6) in response to the first location or the second location matching a location in the list of locations, determining whether one or more regulatory bodies in the first location or the second location regulate the transaction with the online merchant; and (7) in response to determining that the one or more regulators regulate the transaction at the first location or the second location, notifying, over the network, the one or more customers 'computing devices or the one or more merchants' computing devices of the type of regulations under which the transaction is subject. In one embodiment of the invention, the payment service provider module is further configured to: preventing the transaction with the online merchant in response to determining that the one or more curators are regulating the transaction with the online merchant at the first location or the second location.

Further, in embodiments of the present invention, the type of regulation includes a transaction prohibition, a transaction limit, or a transaction tax. Furthermore, in an embodiment of the present invention, the gateway device is an internet service provider server or router or a mobile phone provider server or router. In embodiments of the invention, the transaction may request that an online merchant place a wager, transfer funds to the online merchant, or interest be paid by one or more wagers placed with the online merchant. Furthermore, in an embodiment of the present invention, the one or more databases storing internet protocol addresses of known gateway devices comprises: the server and router addresses of the internet service provider and the server and router addresses of the mobile phone provider.

According to an embodiment of the present invention, there is provided a system for providing information based on a location of a computing device of a user transacting with a third party on a third party website over a network, including a communication interface and a processor configured to execute a verification module. The verification module is configured to: (1) receiving, over a network, a request for approval of a transaction on a third-party website through a communication interface, the request comprising: (a) a first location associated with a physical address of the user and (b) an internet protocol address assigned to the computing device, a website on which the transaction is conducted, and a time and date of the transaction; (2) searching one or more databases storing internet protocol addresses of known gateway devices through a network to identify whether the internet protocol addresses belong to the gateway devices; (3) responsive to the internet protocol address not being associated with the gateway apparatus, searching, over the network, for information at one or more IP geolocation databases to identify a second location corresponding to the internet protocol address and associated with the computing device; (4) requesting information from the gateway device identifying a second location associated with the computing device of the user by providing the gateway device with the internet protocol address, a website on which the transaction is conducted, and a time and date of the transaction in response to the internet protocol address being associated with the gateway device; and (5) providing information identifying the second location over a network connecting the one or more computing devices of the customer or the one or more computing devices of the third party. In an embodiment of the invention, the processor is configured to: in response to the internet protocol address being associated with the gateway device, the authentication module is executed to provide notification that the transaction is blocked.

In accordance with an embodiment of the present invention, a fraud prevention system for identifying a potentially fraudulent online transaction received from a customer for an online merchant is provided. The fraud prevention system includes a processor configured to execute a fraud prevention module to evaluate an online transaction received from a customer using one or more fraud filters. In an embodiment of the invention, the one or more spoof filters are selected from one or more of the following: (1) identifying whether the position where the customer is located is a high cheating position; (2) identifying whether the location of the customer places a limit on the number of credit cards, the size of the purchase, or the number of purchases allowed; (3) identifying a discrepancy between an area identified by a location of a bank that issued a credit card for the online transaction and a location of the customer provided by the customer; (4) identifying a discrepancy between an area identified by the location of a bank that issued a credit card for the online transaction and the location of the customer provided by the customer's internet protocol address; (5) identifying a discrepancy between the area identified by the customer's internet protocol address and the area provided by the customer; (6) identifying a discrepancy between an area identified by where the customer registers the phone number and the location of the customer or bank issuing a credit card for the online transaction; (7) identifying whether any information used by the customer for registration with the merchant has been used for any other account at any other time; or (8) identify that a credit card is used for multiple accounts. Further, the processor is configured to: in response to one or more fraud filters being employed, a fraud prevention module is executed to identify the transaction as potential fraud.

In an embodiment of the invention, the processor is configured to: in response to a fraud filter employed by all online transactions, a fraud prevention module is executed to identify the transaction as potentially fraudulent. Furthermore, in an embodiment of the invention, the processor is configured to: responsive to the transaction being identified as potentially fraudulent, a fraud prevention module is executed to store information associated with the transaction in a fraud database. Further, in embodiments of the invention, one or more fraud filters are selected based on the location of the merchant, the location of the customer, or the location of the bank.

Embodiments of the present invention provide a fraud prevention system for identifying potentially improper online transactions received from a customer for an online merchant. In an embodiment of the invention, a fraud prevention system comprises a fraud prevention module configured to perform the fraud prevention module, the fraud prevention module configured to: (1) receiving a request to conduct an online transaction between a customer and an online merchant; (2) automatically detecting an internet protocol address assigned to a computing device used by a customer to conduct an online transaction; (3) in response to detecting the internet protocol address: (a) searching one or more internet protocol address lists storing one or more known gateway devices; (b) comparing the internet protocol address assigned to the computing device to a list of one or more known gateway device internet protocol addresses to determine whether the internet protocol address assigned to the computing device is on the list of one or more known gateway device internet protocol addresses; (4) identifying the request as potentially improper in response to determining that the internet protocol address assigned to the computing device is on a list of internet protocol addresses of one or more known gateway apparatuses; and (5) in response to the request being identified as potentially improper, storing information associated with the online transaction in an improper transaction database. In an embodiment of the invention, the processor is configured to: in response to the request being identified as potentially improper, a fraud prevention module is executed to deny the online transaction between the customer and the online merchant.

Finally, embodiments of the present invention provide a system for monitoring a patron's compulsive gambling behavior that includes a processor configured to execute an IPSP module. The IPSP module is configured to, in response to receiving a request over the network from a computing device used by the customer to conduct a transaction with an online merchant at the merchant website, evaluate the request using one or more of the following criteria: (1) evaluating a frequency with which a customer deposits at an online merchant to conduct one or more financial transactions with the merchant; (2) identifying differences in the size of one or more deposits made by the customer; (3) evaluating a frequency of requests received from customers to conduct one or more transactions with a merchant; (4) evaluating a time of day or night at which a request is received from a customer; (5) identifying whether some requests received from customers are altered or upgraded; (6) the information identifying the customer indicates that the customer has requested a cool quiet period or requested that transactions be prohibited. Furthermore, in an embodiment of the present invention, the IPSP module is configured to: in response to one or more criteria being employed, one or more of the customer's computing device, one or more computing devices associated with the customer's payment sources, or one or more computing devices associated with the online merchant are notified. In an embodiment of the invention, the processor is further arranged to execute the IPSP module to prevent the request from being processed in response to one or more criteria being employed.

In embodiments of the invention, the processor is configured to execute the IPSP module to notify one or more of the customer's computing device, one or more computing devices associated with the customer's payment source, or one or more computing devices associated with the online merchant in response to all of the fraud filters applicable to the online transaction. Further, in embodiments of the invention, the transaction includes transferring funds from an account associated with the customer to the merchant, or includes placing a wager using funds previously transferred to the merchant.

Furthermore, in an embodiment of the present invention, a threshold value of the frequency of the customer's deposits at the online merchant is set, and the processor is further configured to execute the IPSP module to: (1) in response to receiving a customer's deposit, comparing a frequency of the customer's deposit to a threshold value; and (2) in response to the frequency of the deposit exceeding the threshold, notify one or more of the customer's computing device, one or more computing devices associated with the customer's payment source, or one or more computing devices associated with the online merchant. In one embodiment of the invention, the processor is further configured to execute the IPSP module to prevent the request from being processed in response to the frequency exceeding a threshold.

Finally, according to an embodiment of the invention, a threshold value of the size of the customer's deposit at the merchant is set, and the processor is configured to execute the IPSP module to: (1) in response to receiving a customer deposit, comparing a size of the received customer deposit to a threshold value; and (2) in response to the deposit size exceeding the threshold, notify one or more of the customer's computing device, one or more computing devices associated with the customer's payment source, or one or more computing devices associated with the online merchant. In one embodiment of the invention, the processor is further configured to execute the IPSP module to prevent the request from being processed in response to the size of the deposit exceeding a threshold.

Drawings

Having thus described embodiments of the invention in detail, reference will now be made to the accompanying drawings, which are not necessarily drawn to scale, and wherein:

FIG. 1 is an exemplary block diagram of a financial transaction processing system according to an embodiment of the present invention.

Fig. 2 is a schematic diagram of various contractual relationships in a financial transaction processing system according to an embodiment of the invention.

FIG. 3A is a schematic diagram of a computing device according to one embodiment of the invention.

FIG. 3B is a schematic diagram of a computing device according to another embodiment of the invention.

FIG. 4 is a schematic diagram of a financial transaction processing system according to an embodiment of the present invention.

FIG. 5 is a block diagram of a merchant module according to an embodiment of the present invention.

FIG. 5A is a block diagram of the KYC sub-module according to an embodiment of the present invention.

Fig. 6 is a block diagram of an IPSP module according to an embodiment of the present invention.

Fig. 7A is a block diagram of a fraud prevention sub-module according to an embodiment of the invention.

Fig. 7B is a flow diagram of a fraud prevention sub-module according to an embodiment of the invention.

Fig. 8 is a block diagram of an ASP module according to an embodiment of the present invention.

Fig. 9A and 9B are flow diagrams of an authorization transaction process according to an embodiment of the invention.

Fig. 10A and 10B are flow diagrams of a process for settling a transaction according to an embodiment of the invention.

FIG. 11 is a flow chart of a refund transaction process according to an embodiment of the invention.

FIG. 12 is a flow diagram of a customer payment transaction process according to an embodiment of the invention.

FIG. 13 is a flow diagram of authorizing a transaction request according to one embodiment of the invention.

FIG. 14 is a flow diagram of a settlement transaction request process according to one embodiment of the invention.

FIG. 15 is a flow diagram of a process of monitoring forced expense behavior according to one embodiment of the invention.

FIG. 16 is a flow diagram of a process of monitoring compulsive gambling behavior according to one embodiment of the invention.

FIG. 16A is a flow diagram of another process for monitoring compulsive gambling behavior according to one embodiment of the invention.

FIG. 17 is a flow diagram of a process for determining a tax owed on a financial transaction, according to one embodiment of the invention.

FIG. 18 is a flow diagram of a process of identifying an illegal or regulated financial transaction according to one embodiment of the present invention.

Detailed Description

Various embodiments of the present invention will now be described more fully hereinafter with reference to the accompanying drawings, in which some, but not all embodiments of the invention are shown. Indeed, the invention may be embodied in many different forms and should not be construed as limited to the embodiments set forth herein, but rather should be construed to cover all embodiments falling within the scope of the present invention. In the description, like reference numerals refer to like elements throughout.

Brief summary

In summary, various embodiments of the present invention provide a financial transaction processing system for the e-commerce department that can (1) process payment transactions more securely; (2) to help merchants and banks protect against fraudulent transactions, money laundering, and underage gambling; (3) help limit other abuses in the e-commerce field that are prone to cause special hazards, such as online gaming, travel, and customer purchases of electronic products; and (4) to help reinforce processes and information associated with transactions that result in a reduction in data storage and/or computer processing capabilities. The term "transaction" refers to a business agreement or exchange of two parties. Examples of transactions include, for example, customer registration, setting a guarantee, depositing, paying, and/or picking up from a merchant. To achieve the above objects, an embodiment (1) of the financial transaction system establishes an operation and processing protocol for merchants, internet payment service providers, acquiring banks, and card organizations; and (2) to provide an improved automated system to monitor and process payments and related financial transactions.

For example, in an embodiment of the invention, a recurring reserve committed account is established for each merchant and funded in a manner that reduces the risk of loss to the acquiring or issuing bank. For example, according to one embodiment of the present invention, the risk of loss is reduced by ensuring that sufficient funds are available to process a refund request (e.g., a refund and refund) received by the merchant. According to one embodiment of the invention, a percentage of the funds paid to the merchant are reserved and transferred to the escrow account for a period of time (e.g., 6 months, 1 year, or 3 years), and if the funds are not used for the period of time, the funds are transferred back to the merchant. Because the money funding the recurring reserve committed account comes out of the merchant's potential profit, a solution for money laundering using the merchant's business may be less attractive. Furthermore, in accordance with embodiments of the present invention, the reasons why a merchant may dispute a refund request are limited such that acceptable reasons for dispute do not substantially increase the risk to the acquiring or issuing bank (e.g., transactions marked with a fraud flag). In another embodiment of the invention, the merchant may not be allowed to dispute a refund for any reason. Thus, according to embodiments of the present invention, the backlog escrow account ensures a source of funds for processing the refund request, reduces the risk of loss to the customer and may increase the likelihood of the customer engaging in an online financial transaction. In addition, when the refund request is funded by the merchant, the risk of loss at the acquiring bank and issuing bank is reduced and may result in a more favorable business period for the merchant (e.g., a lower transaction rate or lower refund rate).

As another example, in embodiments of the present invention, participants of a financial transaction system require each other to be subject to a local regulatory authority. For example, in one embodiment of the invention, an internet payment service provider (discussed in more detail below), an acquiring bank, and a card organization may refuse to transact with a merchant if the merchant is not compliant. Alternatively, in another embodiment of the invention, the participant may fine for non-compliant participants. In addition, the customer may also decline to conduct transactions with non-compliant merchants. By establishing this agreement, the financial transaction system is intended to provide a market incentive for participants who remain compliant with local regulatory bodies.

According to embodiments of the present invention, the participants of the financial transaction system may include online customers, online merchants, Internet Payment Service Providers (IPSPs), acquiring banks, issuing banks, or card organizations. The IPSP operates over the network between the merchant and the acquiring bank to provide payment related services for the merchant and to provide an interface between the merchant and the acquiring bank. Further, the IPSP may contract with an Accounting Service Provider (ASP) to provide accounting management services associated with payment services provided by the IPSP to the merchant.

Fig. 1 is a schematic diagram of how the participants work in coordination with each other in an embodiment of the present invention, for example, the participants may exchange transaction information electronically over a network (e.g., the internet, a private network, or a private LAN network). In particular, the transaction information may include: an authorization request from a merchant to transfer money from an account associated with a customer payment card to the merchant's account, an authorization message from an issuing bank to authorize the transfer of money from the customer's account to the merchant's account, a refund (e.g., a refund or refund) request from an issuing bank to transfer money from the merchant's account to the customer's account, and a settlement request for all transactions processed by each merchant during a particular time period (e.g., 24 hours, 48 hours, or a week).

Although the above embodiments describe purchasing goods and services from an online merchant using a payment card (e.g., a debit, credit, prepaid, or proximity card) associated with an account, it will be appreciated that in other embodiments of the invention, other types of payment modes may be used for the purchase. For example, alternative payment modes may include: using a payment token (e.g., a physical token or an electronic token) associated with the account, or using a number associated with the account (e.g., an account number and password for accessing the account). Other payment modes may include authorizing payments using biometric data associated with an account, such as iris scans, fingerprints, and voice recognition. In addition, payment may also be authorized through a combination of account numbers and one-time passwords that may be provided by tokens or through telephone, email, or Short Message Service (SMS).

As briefly discussed above, a financial transaction system according to an embodiment of the present invention provides: (1) an operation and processing protocol for the participant; and (2) automated monitoring and processing systems (e.g., computer software and/or hardware) adapted to process financial transactions with a high level of security, these protocols and automated systems serving to protect customers and participants from fraudulent transactions and other abuse that may create risks in e-commerce transactions. Various examples of protocols implemented by the system are described in detail below in section a, various embodiments of the automated system are described in section B, and exemplary flows of various transactions processed by the financial transaction system are described in detail in section C.

A exemplary protocol

Various embodiments of the financial transaction system provide operational and processing protocols for participants. In accordance with embodiments of the present invention, agreements can be used to prevent organizational crimes and money laundering using the business of merchants, reduce the risk of fraudulent and unauthorized transactions typically associated with online financial transactions, to reduce the risk of loss at acquiring and issuing banks, and to increase the likelihood of compliance with government or local regulatory regulations. For example, according to embodiments of the present invention, a participant should be able to demonstrate compliance with a local or jurisdictional regulatory authority and maintain an auditable record of transactions processed over a particular period of time (e.g., 2 years, 3 years, or 5 years). Further, the agreement may require each participant to prove compliance with local regulatory requirements before contracting with other participants, or the agreement may require the participant to periodically verify that other participants maintain good reputation at the local regulatory body. Various exemplary protocols that may be established for a merchant and an IPSP are described below.

Business company

According to embodiments of the present invention, a merchant may be required to fully disclose the identity of the company director, clerk and beneficiary shareholder and report any changes to the IPSP. Requiring the provision of a listing and comparison of the listing to a listing of persons and entities suspected of participating in an organizational crime may help prevent an organizational crime group from using the business of the merchant to launder money or perform other illegal purposes.

Further, according to embodiments of the present invention, the merchant may be required to take one or more steps to help reduce the risk of loss to the acquiring bank, issuing bank, and customer due to fraudulent transactions. For example, according to embodiments of the present invention, a merchant may be required to: (1) proving compliance with all relevant regulatory requirements, (2) paying penalties if any contractual obligations are violated, (3) verifying payment information and customer information provided during the online transaction using address verification, age verification, and authentication software on the merchant's computing device, (4) performing an initial fraud check on the received payment and customer information, followed by a random or periodic check, or (5) providing notification to the customer using an IP address access system, or to the customer whose billing address provided is associated with the right that the transaction is deemed illegal.

Further, according to embodiments of the present invention, the merchant may be required to execute an agreement to mitigate the risk of abuse (if any) associated with the operation of the merchant or the visible social impact of conducting transactions with the merchant (e.g., a compelling cost if the merchant is an online gaming merchant or an adult entertainment provider). For example, a merchant may be required to provide advice regarding the social impact of its business and help resources (e.g., toll-free phone numbers to help hotlines, websites providing help information, or contact information for consultants). Further, according to one embodiment of the invention, the merchant may be required to provide the merchant's name and toll free number on the customer's payment card listing so that the customer may call the customer service and query for the transaction. According to an embodiment of the present invention, representatives of the customer service should be 24/7 available.

IPSP

According to embodiments of the present invention, the IPSP may be required to implement one or more of the following security features to help prevent an organization criminal group or others from using merchant operations for money laundering purposes and to reduce the risks associated with online financial transactions for various participants: (1) establishing a recycle savings escrow account for each merchant, such as the above-described escrow account, the merchant processing a refund request from the recycle savings escrow account, (2) monitoring the transaction to identify suspicious activity, (3) monitoring the frequency and magnitude of the transaction on a per payment card basis, (4) maintaining the transaction separately for tracking and auditing purposes for each merchant (or web site), (5) periodically (e.g., every 2 seconds or every 10 seconds) saving transaction information to create an audit trial and storing transaction information for a specified period of time (e.g., 1 year, 2 years, or 5 years), (6) verifying the identity of the card holder, (7) requiring the merchant to disclose the company and the beneficiary stakeholder to the IPSP, (8) limiting payment of the winnings from the internet gambling merchant to the card holder, and screening the payee's name from an appropriate sanction list (e.g., "specially designated country list" in the united states, "special designated nationalist), (9) requiring merchants to be approved by appropriate local laws and regulations and to maintain good financial and legal reputations, (10) penalizing merchants found to be in violation of contractual obligations (e.g., by terminating a contract with the merchant or penalizing the merchant), (11) using and being guaranteed by several Tierl acquiring banks operating in well-regulated jurisdictions, (12) requiring merchants to enforce policies, procedures, and standards (e.g., guaranteed by the Account Information Security (AIS) project of VISA) aimed at maintaining card-holder information security, and (13) operating and applying financial action laundering prevention work group (financial action task force on terrorist financing) recommendations (e.g., www.FATF-gafl. org) (e.g., see appendix a/washing back/terrorist financing method (Anti-monying/committing terrorist financing law, incorporated into the methodology 40). Further, in embodiments of the present invention, the IPSP maintains a spoof database 42, as shown in figure 1, for storing information processed by the IPSP that appears or is determined to be spoofing a transaction. According to one embodiment of the invention, the IPSP allows other participants to utilize the fraud database when processing transactions to further reduce the risk of loss to the issuing bank, acquiring bank, merchant and customer. Although the IPSP may manage its own billing and fraud databases, coordinate transactions it processes, and generate coordination reports for merchants, according to another embodiment of the present invention, the IPSP may contract with an ASP to provide one or more of these services. Further, in embodiments of the present invention, the IPSP may also maintain a customer information database 50 for storing customer information.

Further, according to one embodiment of the invention, the exemplary protocol may require that the IPSP create separate corporate entities (e.g., SG1, SG2, SG3, etc.) for each merchant, and that these corporate entities operate under the direction of the IPSP and/or ASP to manage funds received for a particular merchant associated with the corporate entity, as described in more detail with reference to fig. 14. This corporate structure, according to embodiments of the present invention, decouples the operation of each merchant. Further, according to an embodiment of the present invention, this corporate structure provides a legal structure that ensures fair and objective management of the commission funds to protect the financial transaction system and the customer.

Acquiring bank

According to embodiments of the present invention, an exemplary agreement may require an acquiring bank to implement one or more of the following security features to reduce the risk associated with online transactions by the issuing bank and the customer: (1) the online merchants are monitored for credit activity to ensure that customers can receive won money or credits from the merchant onto their payment cards (as directed by the VISA-initiated card holder funds transfer (CFT) and by the Mastercard-initiated money flow (MoneyFlow)), (2) to ensure that all card organization regulations are communicated to the IPSP and merchant, (3) to ensure that transaction information has the correct data elements specified by the card organization and issuing bank, and (4) to ensure that the IPSP is subject to the appropriate regulatory plan.

Engagement between participants

According to embodiments of the present invention, one or more system protocols may be incorporated into the agreement between participants to ensure compliance with the established protocol. For example, FIG. 2 illustrates a schematic diagram of contractual relationships between participants in an embodiment of the invention. In particular, the acquiring bank 36, the IPSP34 and each merchant 31, 32, 33 may enter a three party processing agreement 45 which sets forth each party's responsibility for how the transaction is processed. The agreement 45 may require each party to maintain a good reputation with the local regulatory agency, provide an updated list of supervisors, clerks, and beneficiaries to other parties, perform some authentication and fraud verification of transaction information, and store transaction information for auditing purposes for a particular period of time (e.g., 1 year, 3 years, 5 years). Further, in accordance with one embodiment of the present invention, the commitment 45 may include a reason that one or more merchants may contend for the refund request. According to another embodiment of the invention, the processing contract 45 may establish a fee that the merchant 31, 32, 33 should be charged for the refund.

In addition, the acquiring bank 36 and the IPSP34 may enter a trust agreement 47 setting forth the specific fraud checks that the IPSP should perform on transaction data and when the IPSP should request settlement on behalf of each merchant (e.g., daily or weekly).

The ASP35 and each merchant 31, 32, 33 may enter a commitment agreement 49 that sets forth how the merchant ASP will manage the rolling savings commitment account on behalf of the merchant (e.g., the percentage of funds brought out for the commitment account, the length of time funds are stored in the commitment account, or the format of the reconciliation report).

In addition, ASP35 and IPSP34 may enter a service agreement 43 that sets forth each party's responsibility for billing services provided by the ASP to the IPSP (e.g., the format and accessibility of data exchanged between the ASP and the IPSP, the type and format of summary reports generated by the ASP on behalf of IPSP34 or IPSP34, fee calculations payable to one or more participants, or approval procedures to reconcile the reports for merchant approval). Further, in one embodiment of the invention, the agreement 43 may require the ASP35 to respond to transaction queries from merchants 31, 32, 33 regarding processing by IPSP34 or ASP35 on behalf of IPSP 34. Further, in another embodiment of the present invention, the ASP35 may be required to (a) identify all transaction data processed by the ASP35 on behalf of IPSP34 and (b) forward the identified data to the merchant 31, 32, 33 to determine what further action, if any, the merchant 31, 32, 33 wishes to take with respect to the refund request.

B. Automated system for monitoring and processing transactions

As will be appreciated by one skilled in the art, the present invention may be embodied as a method, a transaction processing system, or a computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present invention may take the form of a computer program product on a computer-readable storage medium having computer-readable program instructions (e.g., computer software) embodied in the storage medium. More particularly, the invention may take the form of website-implemented computer software, which may utilize any suitable computer-readable storage medium, including hard disks, CD-ROMs, optical storage media, or magnetic storage media.

The present invention is described in detail below with reference to block diagrams and flowchart illustrations of methods, apparatus (i.e., systems) and computer program products according to one embodiment of the invention. It will be understood that each block of the block diagrams and flowchart illustrations, and combinations of blocks in the block diagrams and flowchart illustrations, respectively, can be implemented by computer program instructions. These computer program instructions may be loaded onto a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions which execute on the computer or other programmable data processing apparatus create a means for implementing the functions specified in the flowchart block or blocks.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including computer-readable instructions for implementing the function specified in the flowchart or block diagram block or blocks. The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks.

Accordingly, blocks of the block diagrams and flowchart illustrations support combinations of means for performing the specified functions, combinations of steps for performing the specified functions and program instruction means for performing the specified functions. It will also be understood that each block of the block diagrams and flowchart illustrations, and combinations of blocks in the block diagrams and flowchart illustrations, can be implemented by special purpose hardware-based computer systems that perform the specified functions or steps, or combinations of special purpose hardware and computer instructions.

In the embodiments described in this specification, reference is made to a "computer" or "computing device". The computer may be a handheld device such as a mainframe, desktop, notebook or laptop computer, data acquisition and storage device, or may be a processing device disposed in another piece of equipment, such as a wireless telephone. In some cases, the computer may be a "dumb" terminal for accessing data or processors over a network. FIG. 3A illustrates one embodiment of a computing device, which may be used to implement various embodiments of the present invention. In fig. 3A, a processor 1, such as a microprocessor, is used to execute software instructions that implement the specified steps. The processor 1 receives power from the power supply 17, and the power supply 17 also supplies power to other components when required. The processor 1 typically communicates using a data bus 5 that is 16 or 32 bits wide (e.g. in parallel). A data bus 5 is used to transfer data and program instructions, typically between the processor and the memory. In embodiments of the invention, memory may be considered RAM or other forms of main memory 2 that retain content only during operation, or non-volatile memory 3 such as ROM, EPROM, EEPROM, FLASH, or other types of memory that retain storage content at all times. The memory may also be a secondary memory 4, such as a disk memory that stores large amounts of data. In some embodiments of the invention, the disk storage may communicate with the processor using an I/O bus 6 or a dedicated bus (not shown). The secondary memory may be a floppy disk, hard disk, optical disk, DVD, or any other type of mass storage known to those skilled in the computer art.

The processor 1 also communicates with various peripheral or external devices using an I/O bus 6. In embodiments of the present invention, the peripheral I/O controller 7 is used to provide standard interfaces such as RS-232, RS422, DIN, USB or other interfaces suitable for interfacing with various input/output devices. Typical input/output devices include: local printer 18, monitor 8, keyboard 9, mouse 10, or other typical pointing device (e.g., trackball, touchpad, joystick, etc.).

The processor 1 also typically communicates with an external communications network using a communications I/O controller 11 and may use various interfaces such as data communications related protocols 12, e.g., x.25, ISDN, DSL, cable modem, etc. The communications controller 11 may also incorporate a modem (not shown) for interfacing and communicating with a standard telephone line 13. Finally, the communications I/O controller 11 may incorporate an ethernet interface 14 for communicating over a LAN. Any of these interfaces may be used to access a wide area network, such as the internet, an intranet, a LAN, or other data communication facilities.

Further, the processor 1 may communicate with a wireless interface 16 operatively connected to an antenna 15 for wireless communication with another device, using one of the IEEE802.11 protocols, the 802.15.4 protocol, or a standard 3G wireless communication protocol such as CDMA20001xEV-DO, GPRS, W-CMDA, or other protocols.

FIG. 3B illustrates an alternative embodiment of a processing system that may be used, which shows a distributed communication and processing architecture including a server 20 in communication with a local client computer 26a or a remote client computer 26B. The server 20 typically includes a processor 21 (which may be considered a form of secondary storage) and a main memory 24 in communication with a database 22 (such as an SQL database), which also communicates with external devices using an I/O controller 23 that typically interfaces with a LAN25, which may provide local connections to a network printer 28 and a local client computer 26 a. These may be placed in the same facility as the server, not necessarily in the same room. Communication with remote devices is typically accomplished through communications facilities that route data from the LAN25 to a wide area network 27, such as the internet. The remote client computer 26b may execute a web browser to send data over the wide area network 27 to the server 20 over the LAN25 to allow the remote client 26b to interact with the server. Additionally, web browsers may include user interfaces developed in javascript and microsoft.

Those skilled in the art of data networks will appreciate that many other alternatives and architectures can be used to implement the various embodiments of the invention. The embodiment shown in fig. 3A and 3B may be modified in different ways and all fall within the scope of the invention.

FIG. 4 illustrates a computing device 101 according to an embodiment of the invention associated with each participant and communicating with each other over one or more networks 115 (e.g., a private network, a private LAN network, or the Internet). For example, according to one embodiment of the invention, the IPSP34 may establish an IPSP network, which the merchants 31, 32, 33 and the acquiring banks 36 may access by IPSP gateways 40 connecting the IPSP network to the network utilized by the merchants 31, 32, 33 and the acquiring banks 36. According to embodiments of the present invention, the IPSP gateway 40 may be entirely hardware, entirely software, or a combination of hardware and software. In one embodiment of the present invention, by selectively allowing access to the IPSP network, the IPSP gateway 40 may secure information sent to and from the IPSP gateway 40. For example, IPSP gateway 40 may deny merchants 31, 32, 33 or acquiring banks 36 that have no contractual relationship with IPSP34 access to the IPSP network. Further, one or more storage devices may be in communication with the one or more networks 115, which may be one or more of a server, a hard disk, an optical disk, a tape, a flash memory, or a combination thereof. Further, in embodiments of the present invention, the storage device may comprise one or more databases. For example, IPSP34 and/or merchants 31, 32, 33 may be associated with one or more third party databases 116, 117 located in one or more storage devices. In addition, one or more third party systems 118 may also be associated with one or more networks 115.

Furthermore, in accordance with embodiments of the present invention, the acquiring bank 36 may exchange information with the issuing banks 37, 38, 39 using a card organization network, examples of which include, but are not limited to, VISA, MasterCard, and American express networks.

As discussed above with reference to fig. 3A and 3B, according to embodiments of the present invention, merchants 31, 32, 33, IPSP34, ASP35, acquiring bank 36, and issuing banks 37, 38, 39 may be associated with one or more computing devices (e.g., one or more servers, SQL servers, or web servers), one or more of which may include an automated system for processing financial transactions. For example, the system 100 provides a merchant module 200 arranged to run on a merchant's system 101, 102, 103, an IPSP module 300 arranged to run on an IPSP system 104, and an ASP module 400 arranged to run on an ASP's system 105. These modules 200, 300, 400 automate the processing functions of each participant according to one embodiment of the invention. These modules may be implemented entirely as hardware, entirely as software, or as a combination of hardware and software.

Further, according to an embodiment of the present invention, if IPSP34 contracts with ASP35 to provide a billing-related service, ASP module 400 may be configured to run on ASP system 105; alternatively, in another embodiment of the present invention, the ASP module 400 may be configured to run on the IPSP system 104. Various embodiments of these modules are described in more detail below with reference to fig. 5-8.

Merchant module

FIG. 5 shows a block diagram of a merchant module 200 according to an embodiment of the invention. According to embodiments of the invention, the merchant module 200 runs on the merchant systems 101, 102, 103 and automates at least a portion of the steps performed by the merchant in processing the transaction. For example, merchant module 200 is configured to process the authorization request, as shown at step 202. In step 202, the merchant module 200 receives payment information from the customer, which may include some or all of the merchant's full name and billing address, email address, credit card number, CW2 number, payment amount, or card issuer name. The merchant module 200 then verifies the format of the received payment information, such as verifying whether the credit card number is a valid number and whether all fields are complete. The merchant module 200 may also be configured to compare the customer information to previously stored identifications and passwords associated with 3-D security software plug-ins, such as Verify by Visa and securechode by asterCard. If the format is correct, merchant module 200 generates and sends an authorization request to IPSP system 104 for further processing.

In accordance with an embodiment of the present invention, the merchant module 200 is further configured to perform a preliminary fraud check upon receiving the transaction request, as shown at step 206. For example, the preliminary fraud verification step 206 may include comparing the credit card number to a list of stolen credit card numbers, verifying that a billing address provided by the customer matches a billing address of the payment card, comparing the provided billing address to a billing address provided when the customer initially registered with the merchant, or verifying that the name of the card issuer matches the Bank Identification Number (BIN) of the card. In addition, the spoof check step 206 may be performed after the authorization request is sent to the IPSP (step 202), as shown in FIG. 5, or before the authorization request is generated and sent (not shown). In one embodiment of the invention, the fraud verification step 206 is performed after the authorization request has been sent (step 202) but before settlement with the issuing bank.

If no potential problems are detected in the fraud verification step 206, the merchant module 200 verifies the age and identity of the customer, as shown in step 210. For example, age may be verified by checking a card-holder's government record (such as a voter registration record or a driver's license record) or by establishing a network connection with an electronic age and/or identity verification service (such as the URU service provided by the GB group of the UK) and providing the customer's information to the service. According to embodiments of the invention, the service compares the customer's information to government or other public records to verify the customer's identity and age. According to one embodiment of the invention, the merchant module 200 performs an age and identity verification step 210 when the customer establishes a new account with the merchant.

More specifically, embodiments of merchant module 200 may include a "know your customer" (KYC) sub-module 500, a block diagram of which is shown in fig. 5A as KYC sub-module 500 according to embodiments of the present invention. For example, the customer provides certain personal information, such as a birthday. The personal information may be collected at the time the merchant module 200 receives the authorization request, or may be collected prior to this time (e.g., when the customer establishes a new account with the merchant). Further, the personal information may be stored in a memory. For example, merchant module 200 may store the information in a database associated with the merchant (e.g., database 51 associated with merchant 333, shown in FIG. 1). Next, in step 510, KYC sub-module 500 receives this information (e.g., queries the information in memory) to compare the customer's personal information to one or more personal information databases to ensure the validity of the information. One or more personal information databases may be compiled by the merchant in a system accessible to merchant module 200 and may include various commercial third party databases. For example, these databases may be government databases that are remotely accessible by KYC sub-module 500 via a network, or databases in a merchant system, such as merchant system 101. Further, according to embodiments of the present invention, merchant module 200 may collate and/or format information prior to storing the information in a local database, making the information more useful to KYC sub-module 500 and/or other modules that use this information.

In embodiments of the present invention, the customer may provide his or her own range of personal information. For example, the customer may provide information including the full name, birthday, telephone number, email address, social security number, driver's license number, and passport number. In step 520, the KYC sub-module 500 queries various third party systems, such as a voter registration record or driver license record, based on the customer's personal information, which may query its own or other databases to confirm that one or more pieces of information provided in the query match the information found in the databases. Thus, in embodiments of the present invention, the number of matches obtained and the sensitivity of the information provided in the query (to the extent not known to the public) increases the likelihood that the person providing the information does so as to speak to him or her. Thus, in step 530, KYC sub-module 500 determines whether the customer really says he or she is based on the sensitivity of the information in the confirmation query and the information that needs to be confirmed. If KYC sub-module 500 determines that the customer's identity is not verified, KYC sub-module 500 denies the customer's identity (e.g., KYC sub-module 500 notifies merchant module 200 that the customer's identity is not verified), as shown at step 540. If KYC sub-module 500 determines that the customer's identity has been verified, KYC sub-module 500 acknowledges that the customer's identity has been verified (e.g., KYC sub-module 500 notifies merchant module 200 that the customer's identity has been verified), as shown at step 550.

Further, after determining that the provided information is correct and, to some extent, that merchant module 200 is transacting with a verified customer, in step 560, KYC sub-module 500 according to an embodiment of the present invention calculates the age of the customer based on the verified birthday provided in the customer's personal information. For example, the KYC sub-module 500 simply subtracts the customer's birthday from the current date or calculates the age of the customer using the method described above. Thus, merchant module 200 of embodiments of the present invention may allow and restrict certain transactions that customers make with merchants.

With continued reference to FIG. 5, the process of step 210 may be repeated at regular or random intervals thereafter to re-verify the identity and age of the existing customer. Furthermore, in the embodiment shown in fig. 5, the age and identity verification step 210 occurs after the spoof check step 206 and the authorization request step 202. However, according to other embodiments of the present invention, the age and identity verification step 210 may also occur before the authorization request step 202 or the spoof check step 206.

According to one embodiment of the invention, if the age and identity of the customer cannot be verified in the age and identity verification step 210, or a potential problem with the transaction is detected in the fraud verification step 206, the merchant module 200 may notify the customer that the transaction is rejected and notify the IPSP that the transaction is to be rejected, as shown in step 208.

Further, according to embodiments of the invention, the merchant module 200 may be configured to display or otherwise notify the customer of the time spent by the customer on the merchant's website for a particular period of time (e.g., each period, 24 hours, or week). Having this information, the customer may be helped avoid enforcement regarding the merchant's website. Additionally, the merchant module 200 may be configured to allow customers to access customer transaction records maintained by the merchant. Additionally, the merchant module 200 may be configured to enforce autonomic criteria such as limiting losses (gambling transactions) or limiting time and/or money spent on the merchant's website.

To avoid money laundering, the merchant module 200 may also be configured to execute anti-money laundering software (such as software that compares available data to parameters set forth in appendix A of an international money funding organization issued anti-money laundering/terrorist financing method (in conjunction with FATF40+ 9)) to evaluate any transactions of a selected number (such as 15000 pounds or 20000 dollars). The evaluation of the software may include authentication and re-authentication followed by verification of the authenticated individual or company.

IPSP module

Fig. 6 is a flowchart illustrating the IPSP module 300 according to an embodiment of the present invention. According to one embodiment of the invention, the IPSP module 300 is configured to run on the IPSP system 104. According to one embodiment of the invention, beginning at step 302, the IPSP module 300 processes the authorization request received from the merchant system 101, 102, 103. Each authorization request may include payment information for a particular transaction and customer information associated with the transaction, such as the customer's full name, the customer's email address, and the IP address of the computing device used by the customer to initiate the transaction. According to an embodiment of the invention, the IPSP module 300 then sends an authorization request to the acquiring bank system 106, and the acquiring bank system 106 sends the authorization request to the appropriate issuing bank system 107, 108, 109. As discussed in more detail below with reference to fig. 9A and 9B, according to an embodiment of the present invention, the IPSP module 300 receives an authorization message from the issuing bank system 107, 108, 109 through the acquiring bank system 106 authorizing or rejecting the transaction, the IPSP module 300 sends the authorization message to the merchant system 101, 102, 103.

In an embodiment of the present invention, the KYC submodule 500 described above may also be included in the IPSP system 104 instead of or in addition to the merchant systems 101, 102, 103. In these embodiments, one of the merchant systems 101, 102, 103 sends the customer's personal information to the IPSP module 300, and the IPSP module 300 executes the KYC sub-module 500, as shown in step 303. KYC sub-module 500 then performs the steps described with respect to fig. 16A. Thus, in these embodiments, the KYC sub-module 500 is adapted to authenticate customers for some merchants. Further, in these embodiments, the customer's personal information may be stored in memory located in the IPSP system 104, instead of or in addition to memory in the merchant systems 101, 102, 103, such as the customer information database 50 shown in FIG. 1.

According to an embodiment of the invention, the IPSP module 300 stores 304 transaction information (e.g., authorization requests, refund requests, redemption requests, and settlement requests) processed by the IPSP module 300. The stored transaction information may be used for auditing purposes, monitoring the type and frequency of transactions on a per customer, per payment card, or per merchant basis, and generating settlement requests and allocating received funds payments in response to the settlement requests. For example, authorization, refund, and redemption requests may be stored periodically, such as every second or every ten seconds, or on a per transaction basis, such as every time the IPSP module 300 receives and processes transaction information. These requests may be stored for a particular period of time (e.g., a day or a week or longer). Further, in accordance with embodiments of the present invention, the request may be stored on a per merchant basis (or, if the merchant has more than one website supporting electronic commercial transactions, on a per Uniform Resource Locator (URL)). The IPSP module 300 periodically (e.g., daily or weekly) aggregates the authorization requests of each merchant into a settlement request file for each merchant and sends the merchant's settlement requests in a batch file to the acquiring bank system 106 for settlement, as will be discussed below with reference to step 310. The IPSP module 300 may store the aggregated transaction information as separate files for a certain period of time (e.g., one, two or three years).

In an embodiment of the invention, the IPSP module 300 is further configured to execute a fraud prevention sub-module 350, as shown in step 306 of figure 6 and discussed in more detail below with reference to figures 7A and 7B, to verify that the transaction should be settled by the system 100. For example, if the payment card number is listed on a list of stolen payment card numbers, the country of the customer's IP address does not match the country from which the payment card was issued, or the customer is on a list of country sanctions (such as a list of specifically designated countries in the United states), the IPSP module 300 will not display the transaction to be settled. In the embodiment shown in fig. 6, execution of the fraud prevention sub-module 350 occurs after the authorization request processing step 302 and the transaction information storage step 304. However, according to other embodiments of the invention, step 306 may be performed by IPSP module 300 before the authorization request in step 302 is sent to the acquiring bank system 106 or before the transaction information is stored in step 304.

According to an embodiment of the invention, if the fraud prevention sub-module 350 detects potential transaction fraud activity in step 306, the IPSP module 300 is arranged to notify the appropriate party of suspected fraud activity, as shown in step 308. According to embodiments of the invention, suitable parties may include acquiring banks 36 (which may communicate notifications to the issuing banks), issuing banks 37, 38, 39 (directly), merchants 31, 32, 33, and/or customers. Further, according to embodiments of the present invention, the IPSP module 300 is configured to store information regarding potentially fraudulent transactions in the fraud database 42, as shown at step 312. The spoof database 42 may be used by the IPSP module 300 to analyze subsequent transactions. Further, in one embodiment of the present invention, the fraud database 42 may be accessed by the card issuer network and/or the acquiring bank to analyze the received transaction. In addition, the spoofing database 42 may include one or more of the following fields: customer name, address, IP address, payment information (such as card or account number), telephone number, and a code or description identifying previous fraud.

As shown in step 310, if the fraud prevention sub-module 350 does not detect any potential fraudulent activity in step 306, the IPSP module 300 is configured to generate and send a settlement request to either the acquiring bank system 106 or the issuing bank systems 107, 108, 109 in accordance with embodiments of the present invention. The settlement request is based on an authorization, refund, and reimbursement request received by the IPSP module 300 over a specified period of time, such as a day or week. According to one embodiment of the invention, the settlement request may include only those transactions that have not been detected by the IPSP module 300 and merchant module 200 as potential fraud. Alternatively, the settlement request may include one or more transactions that have been detected by the IPSP module 300 or merchant module 200 as potential fraud, but are marked or flagged in the settlement request as potential fraud.

As described above, the IPSP module 300 executes the spoofing preventing sub-module 350 in step 306. An exemplary fraud prevention sub-module 350 is shown in fig. 7A and 7B, according to an embodiment of the present invention. As shown in fig. 7A, the fraud prevention sub-module 350 performs various steps, referred to herein as "fraud filtering," to detect potentially fraudulent transaction activity and may be configured to block or flag a transaction based on the results of a particular fraud filter or a combination of results from a set of fraud filters. In accordance with an embodiment of the present invention, steps 352 and 368 illustrate several fraud filters that may be performed by the fraud prevention sub-module 350. Fig. 7B illustrates the steps performed by the fraud prevention sub-module 350 to determine which fraud filter to apply to the transaction information, in accordance with an embodiment of the present invention.

For example, as shown in step 352 of fig. 7A, the fraud prevention sub-module 350 may compare the payment card information to a list of stolen payment cards. Further, as shown at step 354, the fraud prevention sub-module 350 may compare the location associated with the financial institution that issued the payment card to the location associated with the IP address associated with the customer's computing device. When the transaction information is initially received by the merchant system 101, 102, 103, the IP address associated with the customer's computing device may be obtained by the merchant module 200 (e.g., by using IP address detection software integrated into the merchant module 200). In addition, the fraud prevention sub-module 350 may be configured to compare the location associated with the IP address of the customer's computing device to the billing address of the customer to ensure that the location of the customer's computing device is within a particular range (e.g., 50 miles) of the billing address. Similarly, the fraud prevention sub-module 350 may compare the location associated with the financial institution that issued the payment card to the location associated with the customer-provided email address, as shown at step 356, or compare the location of the IP address of the customer's computing device to the location associated with the customer-provided email address, as shown at step 357. The locations of the above comparisons may include one or more of a country, a region, a state, a region, a county, a city, or a postal area defined by one or more zip codes.

In addition, the fraud prevention sub-module 350 may compare the Bank Identification Number (BIN) of the payment card to a list of suspect BINs, as shown at step 358, and at step 360, the fraud prevention sub-module 350 may identify and indicate a transaction initiated by a customer having a network email address, such as a HOTMAIL or YAHOO email address. In addition, the fraud prevention sub-module 350 may compare the customer's information to a list of individuals that have been edited by the government to be prohibited from making financial transactions with the merchant within government privileges, as shown at step 362. If the customer is identified as being on a list of individuals, groups, and entities that are subject to financial sanctions published by the judicial, such as a list of specifically designated countries published in the united states, the transaction may be denied. Similarly, as shown at step 368, the fraud prevention sub-module 350 may compare the country associated with the IP address of the customer's computing device to a list of countries that are prohibited from conducting transactions with the merchant in certain jurisdictions, and if the country of the IP address is on the list, the transaction may be denied. In addition, the fraud prevention sub-module 350 may compare the customer's information to a list of employees, supervisors, or owners of the online merchants, as shown at step 367, and if the customer is on the list, the transaction may be marked as potentially fraudulent or denied.

According to an embodiment of the invention, the fraud prevention sub-module 350 may also be configured to monitor the frequency of transactions per customer or per card over a specified period of time (e.g., one month, one year), as shown at step 364. In addition, as shown at 366, the fraud prevention submodule 350 may be configured to monitor the type of transaction (e.g., gambling transactions, travel transactions, adult entertainment transactions) for each customer or card during a particular time period. By monitoring the frequency and type of transactions per card or per customer, the fraud prevention sub-module 350 may: (1) identifying potential fraudulent use of the card if the mode of use of the card changes significantly; and (2) identifying potential addiction or abuse if the customer conducts certain types of transactions more frequently or too frequently. According to one embodiment of the invention, the monitoring steps 364 and 366 may be accomplished by establishing a frequency and/or type range for transactions based on previous transactions by the customer and comparing future transactions to the established range. According to other embodiments of the invention, the scope of use of the fraud prevention sub-module 350 may be disclosed by a local government or regulatory agency, may be derived from academic research or institutional research, or the like, or may be established by one or more participants.

Further, according to embodiments of the present invention, the fraud prevention sub-module 350 may be arranged to detect masking or tampering of an IP address associated with a particular transaction. For example, the customer may hide under some firewall or gateway device (e.g., a proxy server or router) to conduct the transaction. Thus, the IP address associated with the transaction is that of a firewall or gateway, and the IP address of the customer's computer is hidden or disguised. In one embodiment of the invention, the fraud prevention sub-module 350 may solve this problem by searching a database storing IP addresses of public gateway devices (e.g., proxy servers) using a filter to compare the IP address associated with the transaction to a list of public gateway devices (e.g., proxy servers). Thus, if the fraud prevention sub-module 350 determines that the customer's IP address is that of a gateway device (e.g., a proxy server), the fraud prevention sub-module 350 marks the transaction as potentially fraudulent or denied.

Further, in accordance with an embodiment of the present invention, the fraud prevention sub-module 350 may be arranged to identify suspicious patterns from the activity of the customer. For example, one mode of fraudulent activity is attempting to use stolen information or stolen credit cards. At this point, the fraud prevention sub-module 350 may be configured to: information is searched for that should be provided by the customer at the time of the use account transaction, but that does not match the customer information for the particular customer account stored in memory.

In addition, the fraud prevention sub-module 350 may identify suspicious patterns by: (1) identifying the position of the customer as a high cheating position; (2) investigating the limit of a particular location on the number of credit cards, size of purchases, or number of purchases allowed; (3) investigating a difference between a location identified by an issuing bank of the card and a location of the customer provided by the customer; (4) investigating the difference between the location of the issuing bank of the card and the location of the customer provided by the IP address of the customer; (5) surveying a discrepancy between the location identified by the customer's IP address and the location provided by the customer; (6) investigating where the identified location is registered by the customer's phone as a discrepancy with the arbitrary location; (7) identifying whether any information for registering or depositing with the merchant has been used at any other time, any other account, to discover related potentially fraudulent accounts (e.g., name and date of birth match, phone number match, address match); (8) identifying that the same credit card uses multiple accounts; (9) identifying that a batch of credit cards from the same Bank Identification Number (BIN) are intended to be used for different accounts for a given period of time (e.g., relative to the speed of a bank, possibly caused by a credit card generator); and (10) identifying a match of the password (e.g., a fraudster may alter all visible information, but would not think of altering the password).

For example, in one embodiment of the invention, the fraud prevention sub-module 350 identifies the first 6 digits (e.g., Bank Identification Number (BIN)) of a credit card number accepted by a customer for a particular transaction. In this embodiment, the fraud prevention sub-module 350 uses the bank identification number to identify the bank that issued the card and the bank's corresponding location. For example, the fraud prevention sub-module 350 queries a BIN directory (e.g., a memory containing a list of known bank identification numbers) that may be stored in a memory located in the IPSP system 104 (e.g., the information database 52 shown in figure 1) or in a memory located outside the IPSP system 104 (e.g., the third party databases 116, 117 shown in figure 4). The query returns the name and/or location of the bank that issued the credit card. In response, the fraud prevention sub-module 350 compares his or her location that the customer has identified with the location of the bank that issued the card for the transaction. If the locations are not the same or are not within an acceptable predetermined range, the fraud prevention sub-module 350 identifies the transaction as a potential fraud. For example, if the customer location identified by the customer is in the united states and the credit card was issued by a bank located in russia, the fraud prevention sub-module 350 identifies the associated transaction as potential fraud.

FIG. 15 illustrates a process of monitoring forced spending behavior according to an embodiment of the present invention. Specifically, beginning at step 502, the IPSP module 300 receives a new request for a financial transaction. In response to receiving the new request, the IPSP module 300 extracts the total amount of funds already stored in the memory 24 associated with the previously requested financial transaction between the particular merchant 31, 32, 33 and the customer, as shown at step 504. In step 506, the amount of the total amount of funds withdrawn and the amount of funds in the new request are compared to the predetermined limits of acceptable funds spent at the merchants 31, 32, 33, and if the total exceeds the predetermined limits of acceptable funds, the IPSP module 300 notifies the appropriate parties (e.g., the customer, issuing bank, and/or merchant) that the limits have been exceeded, as shown in step 508. In an alternative embodiment of the invention, the IPSP module 300 may withdraw the amount of funds stored in memory for a specified period of time (e.g., 24 hours, 36 hours, weeks, months, quarters, years, etc.). In another embodiment of the invention, the IPSP module 300 is configured to compare the number of transactions conducted between the customer and merchant over a specified period of time and if the number of transactions conducted exceeds a predetermined acceptable limit, the IPSP module 300 notifies the customer, issuing bank and/or merchant of: the limit has been exceeded.

Similarly, FIG. 16 illustrates a process for monitoring compulsive gambling behavior according to an embodiment of the present invention. Beginning at step 602, the IPSP module 300 receives a new request for a financial transaction. The new request may include an amount of funds and a type of transaction (e.g., transfer of funds to the merchant, bet with the merchant, request to pay from the merchant). Next, in step 604, the IPSP module 300 extracts the total amount of funds stored in memory 24 for the type of financial transaction in the new request. Subsequently, in step 606, the total amount of funds and the amount of funds in the new request are compared to predetermined acceptable limits associated with the type of financial transaction in the new request. If the total exceeds a predetermined acceptable limit, the IPSP module 300 notifies the appropriate party (e.g., the customer, issuing bank, and/or merchant) of: the limit has been exceeded as shown in step 608. In one embodiment of the invention, if the total number exceeds a predetermined acceptable limit, the new request is rejected. Further, the total amount of funds withdrawn from the memory may be limited to the funds stored for a particular period of time, and the predetermined acceptable limit may be changed depending on the period of time of the query.

Further, according to embodiments of the present invention, the IPSP module 300 may monitor compulsive gambling behavior based upon criteria and the total amount of funds for a particular type of transaction exceeding a predetermined acceptable limit. For example, IPSP module 300 may evaluate: (1) the frequency of the customer's deposits and whether there are any patterns in the size of the deposits, such as increasing the size of the deposits when the customer attempts to win back; (2) the speed at which the customer bets; (3) the time of day or night gambling by the customer; (4) whether the customer's information indicates that the customer has contacted the addictive support center; (5) whether the customer's gambling mode has changed or upgraded; and (6) whether the customer's information indicates that the customer has requested a cool quiet period or requested that gambling be prohibited.

For example, in one embodiment of the invention, the IPSP can establish relationships and network computer links with various organizations that help individuals handle forced gambling problems, and/or establish such organizations (e.g., support centers). These organizations may provide the IPSP module 300 with access to information it uses that is stored in a computer system or storage device. For example, the information may be stored in a storage device (e.g., one or more databases, such as third party databases 116, 117 shown in FIG. 4) that is coupled to the IPSP system 104 and/or the computer systems 118 used by the organizations via the network 115. Thus, in this embodiment, the IPSP module 300 is configured to access and query information based upon the identity of the patron. The IPSP module 300 then evaluates the information to determine if the patron has contacted the organizations.

For example, in one embodiment of the invention, one or more of the computer systems 118 return an indication to the IPSP module 300 that information for a particular customer is stored in the computer system 118 and/or the storage devices 116, 117 associated with the computer system so that the customer has come into contact with such an organization. In another embodiment of the invention, one or more computer systems 118 send an indication of the level (e.g., 1 to 10 or high, medium, low) to the IPSP module 300 located in the IPSP system 104 over the network 115 to determine if the customer exhibits mandatory behavior.

Further, in embodiments of the present invention, the system 118 associated with the organization may send information to the IPSP system 104 of new customers with whom they come into contact over a network seeking compulsory gambling assistance. Accordingly, the IPSP system 104 stores the information in a store (such as the customer information database 50 shown in FIG. 1) located within the IPSP system 104. Thus, in this embodiment, the IPSP module 300 need only query information directly in local storage, and need not query information stored in the systems of several organizations. This may provide for faster processing speeds relative to having to query several different systems 118 associated with these organizations.

Further, according to embodiments of the present invention, the IPSP system 104 may store information indicating that the patron has requested a cool quiet period or requested that wagering be prohibited. For example, in embodiments of the present invention, the IPSP system 104 may provide a service for customers to request a cool quiet period or to be prohibited from gambling. For example, the patron may access a website associated with the IPSP system 104, and the system 104 provides one or more web pages that facilitate the patron's registration for cold quiet periods or for requests to be prohibited from gambling. In embodiments of the invention, the customer may access the service directly on the IPSP system 104 or through the merchant systems 101, 102, 103. That is, in embodiments of the present invention, the IPSP system 104 may provide specific web pages to the merchant systems 101, 102, 103 for use on the merchant's web site.

For example, in other embodiments of the invention, the merchant 31, 32, 33 may provide the customer with a service to request a cool quiet period or be prohibited from gambling through the merchant's website. In this embodiment, the merchant system 101, 102, 103 stores the information in the merchant system 101, 102, 103 and/or sends the requested information to the IPSP system 104 for storage. Thus, the IPSP module 300 may monitor customer activity by querying local information (such as the customer information database 50 associated with IPSP34 shown in figure 1) and/or querying information from various merchant systems 101, 102, 103 (such as the customer information database 50 associated with "merchant 3" 33 shown in figure 1).

Thus, FIG. 16A illustrates another process for monitoring compulsive gambling behavior according to an embodiment of the present invention. Beginning at step 1602, the IPSP module 300 receives a new request for a financial transaction. In response, the IPSP module 300 queries, from storage in the IPSP system 105, or one or more storage in the merchant systems 101, 102, 103, or one or more storage devices 116, 117 associated with the IPSP system 105 via the network 115, information indicating that the individual has contacted various agents to assist the individual in resolving the problem of compulsive gambling, and/or information indicating that the individual has requested a cool period or is prohibited from gambling, as shown in step 1604. Based on this information, the IPSP module 300 determines whether a patron who has submitted a financial transaction request has made contact with one of the organizations, has requested a cool quiet period, and/or has requested that wagering be prohibited, as shown at step 1606. If the customer has contacted one of these organizations, has requested a cool quiet period, and/or has requested wagering be prohibited, the IPSP module 300 contacts the appropriate party (e.g., the customer, issuing bank, and/or merchant), as shown at step 1608. For example, in one embodiment of the invention, the IPSP module 300 automatically sends electronic information, such as an email, to the appropriate party. In another embodiment of the invention, the IPSP module 300 may also deny the request.

Further, in embodiments of the present invention, the IPSP module 300 may be configured to apply for a cold quiescence request or a wager prohibited request at a plurality of merchants. For example, when IPSP module 300 receives a notification over a network from one of the merchant systems 101, 102, 103 that a customer has requested a transaction with a merchant, IPSP module 300 queries personal information that a cold quiet period or that gambling has been requested from a storage device in IPSP system 105, or one or more storage devices in the merchant systems 101, 102, 103, or one or more storage devices 116, 117 associated with IPSP system 105 over network 115, indicates over the network that the merchant system 101, 102, 103 is not permitted to conduct transactions with the customer, and/or lets the merchant system 101, 102, 103 notify the customer (and/or other suitable party) that he or she has requested a quiet period request or that gambling has been prohibited, depending on the queried information indicating that a customer requesting a transaction has requested a cold quiet period or is prohibited by either merchant system 101, 102, 103.

In embodiments of the present invention, a database, such as the information database 52 shown in FIG. 1, may also be maintained to record possible enforcement behavior signals received over the network from the various merchants 101, 102, 103. In addition, thresholds (such as the predetermined acceptable limits on the amount of funds transferred as described above) for additional variables such as the frequency of deposits or the size of deposits may be established and stored in the database. Accordingly, the IPSP module 300 monitors the customer's deposit and notifies the appropriate parties based on these thresholds may help prompt the appropriate parties for enforcement.

In another embodiment of the present invention, a player database of compulsive gamblers identified as possible or authentic may be maintained and accessible by the IPSP module 300. Customer information databases 50, 51 associated with IPSP34 and/or merchants 33, as shown in figure 1, and/or third party databases 116, 117, as shown in figure 4, may be used for this purpose. Whenever a new customer attempts to make a transaction with a merchant known in the gaming industry, the IPSP module 300 checks the database to ensure that the customer is not a forced gambler. If the IPSP module 300 determines that the customer is listed in the database, the IPSP module 300 restricts or inhibits the customer from conducting transactions with a particular merchant.

In addition to monitoring the types of transactions described above, the fraud prevention sub-module 350 may be further configured to monitor return request transactions and identify suspicious transactions, according to embodiments of the present invention. In response to identifying a suspected refund request transaction, such as by identifying a transaction for which the refund request information is inconsistent with information in the original transaction or by identifying a large number of refund request transactions for a particular payment card over a particular period of time (e.g., a week, month, or months), the payment card number may be added to a list of prohibited payment cards, thus preventing future purchase transactions using the payment card.

In addition to the above-described filters, in accordance with embodiments of the present invention, the fraud prevention sub-module 350 may also be configured to (1) ensure that each customer uses only one payment card and (2) limit the payment of certain activities by each customer to a particular frequency (e.g., one payment per day or three payments per 36 hours) at a particular time. Further, according to one embodiment of the present invention, a ceiling of the amount that each card or each customer can spend on a particular service (such as internet gambling or adult entertainment) for a particular period of time (such as daily, weekly or monthly) may be set. In one embodiment of the invention, the ceiling may be set according to customer requirements. In another embodiment of the invention, the IPSP system 104 may introduce a default limit (e.g., 20% of the credit card limit associated with a payment card) on the amount that may be spent on an activity, which cannot be increased without an explicit request from the customer. According to one embodiment of the invention, the IPSP system 104 or merchant system 101, 102, 103 may be configured to present material regarding the risk of excessive spending to the customer, such as by telephone from specially trained employees or email sent to the customer, and display the material (such as gambler anonymous telephone numbers, web site addresses, or other material) upon detection of potential abuse, in response to receiving a request to increase the spending limit.

According to an embodiment of the invention, the IPSP system 104 further includes a fraud and abuse database (not shown) that stores results from the fraud prevention sub-module 350. In one embodiment of the invention, the IPSP module 300 accesses the database when processing the transaction (step 302) or executing a fraud prevention sub-module (step 306) to determine if the transaction should be denied based on previous fraud verification by a particular payment card or customer.

As shown in fig. 7B, the fraud prevention sub-module 350 may evaluate the received transaction information using one or more of the fraud filters described above, according to one embodiment of the invention. Beginning at step 370, the fraud prevention sub-module 350 receives transaction data from the IPSP module 300. Next, in step 372, the fraud prevention sub-module 350 determines that one or more fraud filters are used in evaluating the transaction data. For example, in accordance with one embodiment of the present invention, the fraud prevention sub-module 350 uses a fraud filter that was previously selected for use by the merchant. According to another embodiment of the invention, the type of fraud filter used depends on the type of transaction (e.g., authorization request, refund request, settlement request, or payment request) or stage of the transaction (e.g., whether transaction information has not been sent to the issuing bank or whether transaction information has been authorized by the issuing bank). In yet another embodiment of the present invention, the type of fraud filter used depends on the country of the IP address associated with the customer. In yet another embodiment of the present invention, the selection of which spoof filter should be applied is determined by the IPSP and/or a local authority. Finally, in step 374, the fraud prevention sub-module 350 executes the appropriate fraud filter to evaluate the transaction data.

According to an embodiment of the present invention, the IPSP module 300 is configured for identifying illegal or regulatory-restricted financial transactions in addition to executing the fraud prevention sub-module 350. For example, FIG. 18 illustrates an exemplary process of identifying illegal or restricted financial transactions. Beginning at step 802, the IPSP module 300 receives a request to transfer funds from a customer's payment card to a merchant 31, 32, 33. The request for the funds transfer includes a billing address of the customer and a location of an IP address associated with the computing device used by the customer to generate the request.

In an embodiment of the present invention, the spoofing preventing sub-module 350 uses a third party IP geolocation service to determine the location of the IP address. For example, the spoofing preventing sub-module 350 searches a database provided by the third party IP geolocation service to identify a geographic location corresponding to an IP address or a group of IP addresses. According to embodiments of the present invention, these databases may be accessible via the Internet or may be directly connected to the IPSP system 104.

However, in some cases, the customer's computer uses a gateway device (e.g., firewall, proxy, or router) that masks the personal computer/user's identification, but displays the gateway device's identification (e.g., the spoofing filter described above). For example, the customer's computer may use the gateway devices 60, 62 shown in FIG. 1. Thus, the spoofing preventing sub-module 350 requires an additional search of a database storing the IP addresses of the open gateway devices, such as proxy servers (e.g., third party databases 116, 117 on the network 115 shown in fig. 4). When the fraud prevention sub-module 350 identifies that the IP address belongs to a gateway device (e.g., a proxy server) and the location of a customer hidden behind the gateway device (e.g., a proxy server) cannot be accurately determined or predicted, the fraud prevention sub-module 350 marks the IP address as unrecognizable and restricts the customer from using the IPSP system 104.

In other cases, the gateway device may know the true identity of the customer. Thus, according to an embodiment of the invention, the fraud prevention sub-module 350 may be arranged to: further information identifying the customer, such as the IP address of the customer's computer, is requested from the gateway device over the network 115, and the location of the customer is thus connected to the gateway device.

In some cases, it is not sufficient to use an IP address as the customer's identification. Thus, the fraud prevention sub-module 350 may use other unique identifications in accordance with embodiments of the present invention. For example, when a customer accesses the internet through a mobile phone, the customer passes through a gateway device controlled by the mobile phone provider. At this point, the fraud prevention sub-module 350 receives the IP address of the gateway device associated with the mobile telephone company and provides the mobile telephone company with this IP address, the website associated with the financial transaction, and the time and date of the transaction. In embodiments of the present invention, the fraud prevention sub-module 350 may provide this information in various ways, for example, the fraud prevention sub-module 350 accesses the mobile phone company's system over the internet.

Because additional information and IP addresses are provided, the mobile phone company system can identify the mobile phone that accesses a particular web address, and the mobile phone company can accurately determine the location of the customer based on the base station and provide the customer's location to the IPSP module 300. Thus, the fraud prevention sub-module 350 in this case uses a combination of variables to form a unique identifier that identifies the customer's location, the variables being: the IP address of the mobile phone company system, the website associated with the financial transaction, and the time and date of the transaction.

In another example, customers may access the Internet through various Internet service providers, such as America Online (AOL). As with mobile phone providers, customers may access the internet through a gateway device controlled by AOL. Thus, the IP address of the gateway device received by the fraud prevention sub-module 350 does not match the IP address of the customer's computer. In response, the fraud prevention sub-module 350 provides the AOL with the IP address, the website associated with the financial transaction, and the time and date of the transaction. The AOL uses this information to identify the customer's location and provides the customer's location to the IPSP module 300. Other embodiments of the invention may use many other variable or variables to provide unique identification, such as variables associated with the Global Positioning System (GPS), enhanced observed time difference (E-OTD), cell global identification with time advance (CGI-TA), and uplink time of arrival (TOA).

Next, in step 804, the IPSP module 300 compares the customer's billing address, the location of the IP address and the location of the merchant 31, 32, 33 with a list of locations to manage the transfer of funds to the merchant 31, 32, 33. The location list may be stored locally in the IPSP (e.g., information database 52 shown in fig. 1) or remotely in one or more third party databases (e.g., third party databases 116, 117 shown in fig. 4). If any of these locations match a location on the list of locations, the IPSP module 300 determines whether one or more authorities manage the transfer of funds at any of these locations, as shown in step 806. If the IPSP module 300 determines that one or more authorities are managing the transfer of funds, the IPSP module 300 notifies the appropriate parties (e.g., the customer, merchant, and/or issuing bank) that the transfer of funds is subject to one or more regulations, as shown in step 808. The types of regulations to which financial transactions are subject include prohibited transfers (e.g., gambling transactions in a state or region where gambling is illegal) or restricted transfers (e.g., gambling transactions in a state or region where the amount of funds wagered is limited).

Furthermore, in embodiments of the present invention, the location list may include not only locations where the financial transaction is illegal or subject to regulatory restrictions, but also locations where opt-out is allowed for the financial transaction. For example, a state may opt out of allowing transactions, although the transactions are not technically illegal. Thus, the IPSP module 300 compares the location of the customer's billing address, the location of the IP address, the location of the merchant 31, 32, 33 with the drop-out list and inhibits the transaction if any of the three locations are found on the drop-out list. In other embodiments of the invention, the exit list may include additional variables, such as certain industry options to exit certain types of transactions.

ASP module

Fig. 8 is a block diagram illustrating an ASP module 400 according to an embodiment of the present invention. Although the ASP module 400 may be configured to operate on the ASP system 105 according to an embodiment of the present invention, the ASP module 400 may be configured to operate on the IPSP system 104 if the IPSP does not contract with the ASP to provide the billing management service according to another embodiment of the present invention.

Beginning at step 402, according to one embodiment of the invention, the ASP module 400 obtains transaction information from the IPSP system 104 and the acquiring bank system 106. The transaction information obtained from the IPSP system 104 may include the following data fields for each transaction: (1) a merchant identification (MED) number, awarded by an acquiring bank, to identify the merchant or a transaction entity (e.g., a particular website) of the merchant; (2) date and time of transaction; (3) the name of the customer; (4) a payment card number or partial payment card number (e.g., last four digits); (5) the card-holder's email address; (6) the currency of the transaction; (7) the type of payment card used (e.g., Visa, MasterCard, or american express); (8) paying the amount; (9) the merchant's assigned order reference number to the transaction; (10) an authorization code, which is a unique code generated by the issuing bank, indicating whether the transaction is authorized; (11) the settlement status of the transaction (e.g., "100" for completed transaction); (12) "settlement time", is the time that the IPSP sends a settlement request to the acquiring bank; (13) street and street numbers of the cardholder; (14) the card holder's town; (15) the country of the card holder; (16) the zip code of the card-holder; (17) an originating transaction reference, in the case of a redemption request, to be a reference to the redeemed original transaction; (18) order information that the merchant can use to include more information about the transaction, if desired; (19) "location reference", is the merchant's IPSP reference; (20) transaction types, which may include authorized transactions, refund transactions, and cancelled transactions (such as cancelled transactions, or transactions that change in amount at the merchant's request before money is transferred to the merchant by the issuing bank and after a settlement request is sent from the IPSP to the acquiring bank); and (21) a Unique Reference Number (URN) that uniquely identifies the transaction in the ASP system 105. This information may also be included in a settlement request sent from the IPSP to the acquiring bank, discussed above with reference to step 310 in figure 6, and discussed below with reference to steps 1102 and 1104 in figure 10A, in accordance with an embodiment of the present invention. The transaction information obtained from the acquiring bank system 106 may include a total amount of funds requested from the issuing bank, e.g., the total amount of funds each merchant aggregates in one or more batches.

In order to obtain transaction information, the ASP module 400 may access a secure web page (e.g., maintained by each system 104, 106) having the transaction information posted thereon and download the information to the ASP system 105 and/or receive the transaction information via another type of electronic transmission (e.g., via email or fax), according to embodiments of the present invention.

In embodiments of the present invention, the transaction information obtained in step 402 is stored in the ASP system 105, as shown in step 404, and the information obtained from the IPSP system 104 is compared to the information obtained from the acquiring bank system 106, as shown in step 406. In the embodiment shown in fig. 8, step 406 occurs after step 404, however, in other embodiments of the present invention, step 404 and step 406 may occur simultaneously or in reverse order.

According to an embodiment of the invention, in a comparison step 406, the ASP module 400 identifies any transactions for which the transaction information provided by the IPSP system 104 does not match the information provided by the acquiring bank system 106. In one embodiment of the invention, any unmatched transaction identifications are reported to the merchant, IPSP and/or acquiring bank in an exception report generated by the ASP module 400, as will be described in more detail below with reference to step 410. In another embodiment of the invention, the acquiring banking system 106 transfers funds directly to accounts associated with each merchant and maintained by the IPSP36 and/or ASP35 (described below with reference to figure 14), the ASP module 400 is further configured to compare transaction information provided by the IPSP system 104 and the acquiring banking system 106 with the amount transferred to each merchant account.

After reconciling the transaction information provided by the IPSP system 104 and the acquiring bank 106, the ASP module 400 may distribute the payment amount received during the settlement process to the participants as shown in step 408 of fig. 8. For example, the payment amount may include the amount paid to the merchant 31, 32, 33, the commission owed to the IPSP34, the acquiring bank 36 and the ASP35, and the percentage of funds stored in the recycle savings escrow account 41 for each merchant 31, 32, 33. For example, according to embodiments of the present invention, each participant may ask for: a certain percentage of the funds received by the merchants 31, 32, 33 are paid for their contracts 43, 45, 47, 49 with the merchants 31, 32, 33 and services between each other. For example, the acquiring bank 36 may charge 3% of the funds received by the issuing bank 37, 38, 39 from the merchant 31, 32, 33, the card organization may charge 1% of the funds transferred using their card, the IPSP34 may charge 5% of the payment related services, and the ASP35 may charge 3% of the money received by the IPSP34 for the billing management services. As another example of the invention, the ASP35 may also calculate temporary costs incurred by the IPSP34 for various services, such as card verification, commission payments to seed participants, and any fees chargeable to the merchant 31, 32, 33 due to the refund received.

Further, according to embodiments of the present invention, the financial transaction system 100 may establish a percentage agreement specifying funds used to fund the circulating savings entrustment account 41. For example, the system protocol may require the ASP module 400 to allocate 7.5% of the funds to be received by each merchant 31, 32, 33 to the recurring savings escrow account of each merchant 31, 32, 33. In another example, according to one embodiment of the invention, the specified percentage for the loop savings account may be automatically increased or decreased depending on the number of refund requests received for a particular merchant 31, 32, 33. Further, according to one embodiment of the invention, the ASP module 400 monitors and identifies funds remaining in the account for a predetermined period of time (e.g., six months, one year, or three years) and reallocates those funds to the merchant 31, 32, 33 at the end of the period of time. In the embodiment shown in fig. 1, the proxy account 41 is only a part of the ASP system 35. However, in other embodiments of the invention, the delegated account 41 may reside at or be maintained by a bank or other financial institution.

Next, in step 410, the ASP module 400 is configured to generate a reconciliation report or "advice notice" for each merchant in accordance with embodiments of the present invention. In one embodiment of the invention, the advice notice provides each merchant with a summary of the transactions processed for the merchant over a particular period of time (e.g., one day or one week), the exception report created in the reconciliation step 406 (if needed), the payment summary assigned to each participant in step 408, the activity summary in the delegated account over a particular period of time, and the date on which the payment was transferred to the merchant 31, 32, 33. In another embodiment of the present invention, portions of the advice notification may be included in separate reports (e.g., exception report, payment allocation report, and transaction summary report). In yet another embodiment of the present invention, the ASP module 400 is configured to generate one or more summary reports for IPSP34 and each merchant 31, 32, 33 according to a particular format specified by IPSP34 and each merchant 31, 32, 33, respectively.

In the embodiment shown in fig. 8, the ASP module 400 is further arranged to: (1) sending a proposal notice to the IPSP34 for each merchant 31, 32, 33 for approval as shown in step 412, and (2) upon receiving approval of the proposal notice from the IPSP34 as shown in step 414, sending a proposal notice to the merchant 31, 32, 33 as shown in step 416. In another embodiment of the present invention, the IPSP34 does not have a contract (not shown) with the ASP35 to provide billing management services, and steps 412 and 414 may not be performed.

Further, according to an embodiment of the present invention, the ASP module 400 is arranged to prepare and send payments to the participants and the delegated account, as shown in step 418. For example, step 418 may include: physically sending payment (such as check or cash) to each participant, preparing to request an electronic funds transfer (electronic funds transfer eft) from an account associated with the ASP system 105 to an account associated with each participant owed money, or a combination of both. Furthermore, although in the embodiment shown in fig. 8 the payment step 418 occurs after step 416, according to other embodiments of the present invention, the ASP module 400 may be arranged to: the payment step 418 is performed simultaneously with the step 416, or the payment step 418 is performed before the step 416.

In other embodiments of the present invention, the ASP module 400 may be further configured to: local or regional taxes for the associated electronic commercial transaction (e.g., an internet gambling transaction or retail purchase) are withheld before payment is sent to each merchant 31, 32, 33. For example, in one embodiment of the present invention, the ASP module 400 may be configured to apply an applicable tax rate or approval rate to transfer funds directly to an associated tax or approval authority based on the residence or the location of each customer and/or merchant's transaction.

In particular, FIG. 17 illustrates an exemplary billing process for any taxes owed on a financial transaction. Beginning at step 702, the appropriate types of taxes and corresponding tax rates for one or more tax jurisdictions are stored in memory 24. Next, in step 704, information associated with financial transactions conducted between the customer and the merchants 31, 32, 33 is received. In response to receiving the information associated with the financial transaction, one or more related tax jurisdictions associated with the financial transaction are identified, as shown at step 706. Next, in step 708, a memory is queried to determine one or more taxes associated with the identified tax jurisdiction. If one or more taxes are associated with the identified tax jurisdiction, then a tax rate corresponding to the type of tax is applied to the financial transaction to determine the tax owed to the transaction, as shown in step 710. In addition, once the tax owed to the transaction is determined, the amount of the owed tax is communicated to the associated tax authority, as shown at step 712. In embodiments of the present invention, taxes may be imposed based on the transaction initiator (e.g., merchant), the location of the customer, and/or the location of the computing device from which the customer places the order.

In the embodiment of the present invention, the same systems and processes as those described above can also be applied to the license fee. For example, similar to a driver's license or a fishing license, an individual must pay a certain license fee to the government in order to obtain a license to play a bet. Thus, beginning at step 702, the appropriate licensing fees and corresponding licensing rates for one or more authorized jurisdictions are stored in memory 24. Next, in step 704, information associated with financial transactions conducted between the customer and the merchants 31, 32, 33 is received. In response to receiving the information associated with the financial transaction, one or more relevant authorization jurisdictions associated with the financial transaction are identified, as shown at step 706. Next, in step 708, the memory is queried to determine one or more relevant license types. If one or more of the permission types are associated with the identified authorized jurisdiction, the permission rate corresponding to the permission type is used for the financial transaction to determine a license fee owed to the transaction, as shown in step 710. Further, once the royalty owed for the transaction is determined, the amount owed is transferred to the relevant authorized jurisdiction, as shown at step 712. In embodiments of the invention, a license fee may be imposed based on the transaction initiator (e.g., merchant), the location of the customer, and/or the location of the computing device from which the customer places the order, as with a tax.

In embodiments of the invention, the amount of taxes deducted and the amount paid to the tax authority are stored in a system with transaction information over a period of time, allowing for a complete audit trail. For example, in one embodiment of the invention, the amount due is held in a designated bank account and paid to the tax authority periodically (e.g., monthly, weekly, daily, or instantaneously). In one embodiment of the invention, the amount due is paid to the tax authority by an Electronic Funds Transfer (EFT).

According to the embodiment of the invention, the tax accounting function relieves the burden of merchants, customers and tax authorities and provides a credible accounting system for tax transactions. Further, in one embodiment of the invention, the ASP module 400 generates a billing report for the tax authority summarizing the tax due and/or the tax amount that has been billed.

Further, in embodiments of the present invention, the transaction records may be audited electronically or manually by the ASP module 400. In particular, as transactions are processed through the system, a Unique Reference Number (URN) associated with each transaction is tracked. For example, in one embodiment of the invention, multiple transactions may be grouped into a batch file and sent to an acquiring bank for settlement. The ASP module 400 stores the URN associated with each transaction and information identifying the batch file in the batch file so that each individual transaction can be independently audited.

C. Exemplary Process flow

Authorization process flow

Fig. 9A shows a flow diagram 1000 for processing an authorization request according to an embodiment of the invention. In one embodiment of the invention, the processing of the authorization request occurs online while the customer is waiting, and typically takes two to twenty seconds to process. If the authorization request is accepted by the issuing bank, the merchant accepts the customer's payment, and the issuing bank prevents the requested amount from exceeding the credit limit or balance associated with the payment card.

The authorization request process 1000 begins at step 1002 by the merchant 31, 32, 33 receiving a request from a customer to transfer money from the customer's payment card to the merchant's account, according to an embodiment of the present invention. The request may include, for example, the amount of the transfer and the customer's information and payment card information (assuming the merchant did not store the customer's information and payment card information in previous transactions). In one embodiment of the invention, the customer and payment card information may include the customer's full name and address, the customer's email address, the payment card number, the expiration date, and any other identifying information associated with the payment card. In one embodiment of the invention, the request may be received by the merchant system 101, 102, 103 and stored on the merchant system 101, 102, 103.

Next, in step 1006, the merchant 31, 32, 33 verifies the format of the information received in the customer's request, in accordance with embodiments of the present invention. In one embodiment of the invention, the merchant module 200 verifies that the format of the payment card number is correct, and that all required fields have been completed, as described above in connection with the merchant module 200 and step 204 shown in FIG. 5.

After verifying the format of the information in step 1006, the merchant 31, 32, 33 transmits the transaction information to IPSP34 for further processing, as shown in step 1010. IPSP34 receives and stores the transaction information on IPSP system 104 and sends the acquiring bank 36 and issuing banks 37, 38, 39 required information to the acquiring bank 36 to process the authorization request as shown in step 1012. For example, according to embodiments of the present invention, information may be transferred by the IPSP module 300 to the acquiring bank system 106 and may include a payment card number, payment amount, and a customer's billing address.

Next, in step 1014, the acquiring bank system 106 receives the authorization request and stores the authorization request on the acquiring bank system 106. Then, in step 1016, the acquiring bank system 106 identifies the appropriate card issuer and issuing bank, and routes the authorization request to the issuing bank through the appropriate card issuer network (e.g., Visa, Mastercard, or american express network). Upon receiving the authorization request, the issuing bank system 107, 108, 109 verifies that the payment card is operational and valid, as shown at step 1018, and that there are sufficient funds for the payment card, as shown at step 1020. Upon approving the authorization request, issuing bank system 107, 108, 109 sends an approval message to acquiring bank system 106 via the card issuer network, as shown in step 1022, acquiring bank system 106 receives the approval message and sends the approval message to IPSP system 104 in step 1024. The IPSP system 104 then receives and stores the approval message and sends the approval message to the merchant system 101, 102, 103 that initiated the authorization request in step 1026.

In accordance with embodiments of the present invention, the primary fraud verification and identity/age verification steps (steps 204 and 206) discussed above with reference to FIG. 5 may be performed by the merchant module 200 at the same time, before, or after the step 1010 of transferring the authorization request information from the merchant to the IPSP. Further, according to embodiments of the present invention, the step of performing the fraud prevention sub-module 350, step 306 shown in FIG. 6, may be performed by the IPSP module 300 concurrently with, before, or after the step 1012 of transferring the authorization request message from the IPSP to the acquiring bank.

In another embodiment of the invention, as shown in FIG. 13, the customer's information is encrypted (e.g., with 2048 bit variable encryption) when sent to the merchant system 10la, 102a, 103a and to the IPSP system 104a via the network 115 a. In addition, the IPSP module 300a implements one or more fraud filters of the fraud prevention sub-module 350a, and if a potential suspicious activity is detected by the fraud filters, the IPSP module 300a sends the results of the fraud verification to the merchant for approval before sending an authorization request to the acquiring bank system 106 a. After the merchant provides approval of the transaction, the IPSP module 300a sends an authorization request to the acquiring bank, which then sends the request to the issuing bank. After the acquiring bank receives the authorization message from the issuing bank, the acquiring bank stores the transaction information in a storage area of the acquiring bank system 106a (e.g., a database) and sends the authorization message to the IPSP system 104 a. The IPSP module 300a forwards the authorization message to the merchant and may perform one or more fraud filters on the transaction information prior to generating a settlement request for the transaction.

Settlement processing flow

Fig. 10A and 10B illustrate an exemplary flow diagram 1100 for processing a settlement request according to an embodiment of the present invention. According to an embodiment of the present invention, the settlement request is a request generated by the acquiring bank (or the IPSP on behalf of the acquiring bank) to transfer money from the issuing bank to the acquiring bank to be paid to the merchant. The settlement request process 1100 begins at step 1102, where the IPSP system 104 generates a settlement request for each merchant 31, 32, 33 and transmits the settlement request in a batch file to the acquiring bank 36, according to an embodiment of the present invention. In embodiments of the present invention, each settlement request contains transaction data processed by IPSP34 over a specified time period (e.g., 24 hours, 48 hours, or a week). According to embodiments of the present invention, the settlement request may include both authorized and unauthorized transactions or only authorized transactions. Next, in step 1104, the IPSP system 104 stores the settlement request on the IPSP system 104, in accordance with an embodiment of the present invention. The settlement request may be transferred to the ASP system 105 by downloading from a secure portion of the IPSP system 104, or the IPSP34 may send a physical or electronic copy of the settlement request to the ASP35 (e.g., via email, fax, CD, DVD, or floppy disk). The contents of the settlement request according to the embodiment of the present invention have been described above with reference to fig. 8.

The acquiring bank 36 receives the batch file and sends a settlement request to the appropriate issuing bank 37, 38, 39, as shown at step 1106. In addition, acquiring bank 36 generates and stores a payment report for ASP35 to summarize the amount of funds (e.g., the aggregate amount of funds) included in each settlement request for each issuing bank 37, 38, 39, as shown at step 1108. One embodiment of a payment report generated by the acquiring bank 36 for the ASP35 has been described above with reference to fig. 8.

Next, in step 1110, the issuing bank 37, 38, 39 transfers the requested funds to the acquiring bank 36. Next, in step 1112, the acquiring bank 36 transfers the received funds to the IPSP 34. Before the IPSP34 (or ASP35) dispenses funds to the appropriate participants and commitment accounts, the ASP system 105 obtains settlement requests generated by the IPSP system 104 and payment reports generated by the acquiring bank 36 and reconciles the obtained information in step 1114. The results of the reconciliation performed in step 1114 may be summarized by the ASP35 as a reconciliation report (or "advice notice"), according to embodiments of the present invention. Finally, in step 1116, the ASP35 arranges each participant's payment and amount for transfer to the delegated account and transfers the payment to the participants and delegated account.

According to one embodiment of the invention, the ASP module 400 is arranged to perform steps 1114 and 1116, as already described above with reference to fig. 8. For example, the ASP module 400 summarizes the results from reconciliation data provided by the IPSP and acquiring bank in reconciliation reports sent periodically (e.g., daily or weekly) to each merchant 31, 32, 33. The reconciliation report summarizes the amount that the merchant 31, 32, 33 may wish the merchant's bank account to receive before a particular date. Further, the reconciliation report includes the total amount of the customer placed in the respective merchant account and shows the following deductions and increases: (1) minus commissions and fees (covering payments to all participants in the payment chain); (2) a "trust exemption" that is subtracted by the percentage of the total amount that remains in the recurring savings commitment account as secured for refunds and refunds for a particular period of time (e.g., six months or a year); (3) adding "trust money" that remains within a certain time period and the day before the date of the proposed notice; (4) minus any refunds sent by the acquiring bank on the day of the advice notice regarding the previous transaction. The IPSP34 examines the reconciliation report, including the date indicating that payment has been paid, before transferring funds to the appropriate participant and the recurring storage commitment account. Upon receiving approval of the IPSP34 for the reconciliation report, the ASP35 sends the reconciliation report to the various merchants 31, 32, 33 and transfers the payment to the appropriate participants and delegated accounts. In one embodiment of the invention, the transfer of funds may occur after the reconciliation report is generated and approved. In another embodiment of the invention, the transfer of funds may occur before the reconciliation report is approved.

According to an alternative embodiment shown in fig. 14, funds are deposited directly by the acquiring bank into accounts of each corporate entity associated with each merchant (e.g., SG1, SG2, SG3, etc.). Further, the ASP module 400a is arranged to coordinate the receipt of the number of accounts each having a settlement request and payment reports obtained from the IPSP and the acquiring bank respectively. In one embodiment of the invention, no amount is paid from the account to each participant or to the principal account to the merchant.

Refund processing flow

The refund request is a request initiated by the issuing bank on behalf of the customer to redeem a particular fee against the customer's payment card account. For example, in response to a customer dispute regarding a fee on a customer's payment card: the customer claims that the customer is not authorized and the issuing bank may initiate a refund request. FIG. 11 illustrates an exemplary flow diagram 1200 for processing a refund request according to an embodiment of the present invention.

Beginning at step 1202, the issuing bank 37, 38, 39 receives a refund request from a customer. Then, in step 1204, the issuing bank 37, 38, 39 sends a refund request to the acquiring bank 36. In step 1206, the acquiring bank 36 receives the refund request and sends the refund request to the IPSP 34. Next, in step 1208, IPSP34 compares the refund request to data from the original transaction. If the data in the refund request matches the data from the original transaction, the IPSP34 sends the request to the ASP35 in step 1210. According to the above-described embodiment of the present invention, the comparing and transmitting steps 1208 and 1210 may be performed by the IPSP module 300. Next, in step 1212, the ASP35 transfers the refund amount from the merchant's committed account to the acquiring bank 36, and the acquiring bank 36 then transfers the refund amount to the issuing bank 37, 38, 39 that initiated the refund request, in accordance with an embodiment of the present invention. In an alternative embodiment of the present invention, the ASP35 transfers the refund amount from the merchant's escrow account to the acquiring bank only if the customer cannot directly pay the refund amount, such as when insufficient funds, bankruptcy, inability to pay, and/or the merchant is no longer operating. In another alternative embodiment of the present invention, the ASP35 pays the refund amount to the issuing bank 37, 38, 39 by deducting the refund amount from the total amount that should be paid to the merchant 31, 32, 33 in the settlement request. Next, in step 1214, the ASP35 stores the refund request. In an embodiment of the present invention, the ASP module 400 is arranged to perform steps 1212 and 1214.

According to embodiments of the present invention, if the refund request data does not match the data from the original transaction in step 1208, the refund request may be flagged. Further, if the number of refund requests flagged as being associated with a particular payment card exceeds a certain number within a particular time period (e.g., two refund requests within a week or month), the IPSP may include the particular payment card number on a list of payment cards for which the merchant will not accept payment in the future (e.g., in a fraud and abuse database maintained by IPSP 34).

In addition to the above, according to embodiments of the present invention, the ASP35 coordinates refund requests processed by the acquiring bank 36 and the IPSP34 over a particular period of time (e.g., daily or weekly) with transaction data from the original transaction. To coordinate the request, the ASP35 obtains the refund transaction report generated by the acquiring bank 36 and the refund transaction report generated by the IPSP34 and compares the two refund transaction reports with the data from the original transaction, as shown in step 1216. In one embodiment of the present invention, the comparing step 1216 is performed by linking the data in the refund report with the raw transaction data from what has been stored in the memory of the ASP system 105. According to one embodiment of the invention, the refund data report contains at least part of the following information: (1) referencing an original transaction that was refunded; (2) an MID number; (3) date of chargeback request; (4) a description of a transaction as a "refund"; (5) a complete card number; (6) a reference number secured by the acquiring bank; (7) a "reason code", a code number issued by the card issuer indicating the reason why the card-holder initiated the refund; (8) a description of a reason for initiating a refund; (9) a refund amount of currency type; (10) the number of refunds; (11) a card number or a part of the card number (such as the first four digits of the card number) provided by an acquiring bank; (12) date the original transaction was "released" or authorized; (13) the date the original transaction occurred; (14) "type" of original transaction; (15) currency of the original transaction; (16) the amount of the original transaction; (17) currency of settlement of the transaction; (18) the amount of settlement; (19) the original "default" currency provided by the acquiring bank; (20) the original "default currency" amount provided by the acquiring bank; (21) "original order", which is a reference to a "batch" transaction, is a part of the acquiring bank releasing its transactions on a particular date to the IPSP; (22) "project sheet" of acquiring bank; (23) an authorization code of the original transaction; (24) the "batch number" of the acquiring bank; and (25) "merchant DBA name", is the name that the merchant displays on the customer's payment card statement. As described above with reference to fig. 8, the ASP module 400 may be arranged to perform the co-ordinating step 1216 according to an embodiment of the present invention.

According to embodiments of the present invention, the report may be published onto the IPSP system 104 and the acquiring bank system 106 and may be downloaded by the ASP system 105; alternatively, the report may be sent physically or electronically via, for example, email, fax, CD, DVD, or floppy disk.

Payment processing flow

In some electronic commerce (e.g., gambling) money may need to be refunded to the customer. Paying out customer money may raise concerns about the risk of abuse of money laundering, especially for internet gambling. According to embodiments of the present invention, the system 100 may address some of the risks associated with electronic commercial transactions by creating a completely transparent "closed loop" between the customer and the merchant by paying exclusively to the payment card account used by the customer to make the original payment to the merchant. Thus, according to one embodiment of the present invention, funds originate and flow back to the same account and all of the funds flow is traceable, making electronic commerce unattractive for money laundering programs.

For example, FIG. 12 illustrates an exemplary process 1300 for processing and sending a payment to a customer when the customer submits a payment request. Beginning at step 1302, a merchant receives a request for payment from a customer and sends the request to an IPSP. Next, in step 1304, the IPSP verifies that the patron is not included on a government or local agency sanction list (e.g., a "specially designated countries list" published by the United states). Further, according to one embodiment of the invention, the IPSP verifies that the guest's nationality (e.g., based on the customer's billing address or the IP address of the customer's computing device) is not on the banned national list where the merchant may conduct transactions. According to embodiments of the present invention, if the customer (or the customer's country) is on the list, the payment request cannot be processed by the system 100 and the request is denied. If the customer is not included on the sanction list (or is not associated with a prohibited country), the IPSP34 sends a payment request to the merchant's bank, as shown in step 1306. In response to receiving the request and verifying that the payment funds are in the merchant's account, the merchant bank transfers the funds to IPSP34, as shown in step 1308. After the IPSP34 has received the funds and stored a record of the funds in the IPSP system 104, the IPSP34 transfers the funds to the acquiring bank 36, as shown in step 1310. Next, in step 1312, upon receiving the funds, the acquiring bank 36 passes the funds to the issuing bank 37, 38, 39 associated with the payment card that the customer uses to make a purchase (e.g., make a wager) on the merchant's website. In step 1314, the issuing bank 37, 38, 39 may then trust the account associated with the payment card for the amount received from the merchant 31, 32, 33, according to embodiments of the present invention; alternatively, the issuing banks 37, 38, 39 may issue checks to customers listed as card holders.

Electronic purse

In another embodiment of the invention (not shown), the financial transaction system 100 is configured to allow a customer to purchase electronic tokens from IPSP34, which can then be used to agree on a price with participating merchants 31, 32, 33 to create a prepaid "e-wallet" account. According to embodiments of the present invention, the features of the financial transaction system 100 may be extended to an electronic wallet system. For example, rather than the merchant 31, 32, 33 receiving a request from the customer to transfer funds from an account associated with the customer's payment card to a merchant account, the IPSP34 receives a request to transfer funds from the customer's e-wallet account to an IPSP account. According to one embodiment of the invention, IPSP34 performs the steps of merchant module 200 and IPSP module 300 to generate and process authorization and settlement requests with the issuing bank. Once settled, the IPSP34 credits the customer's electronic wallet account with an amount of electronic tokens representing the amount of funds transferred. The customer may make purchases using tokens and participating merchants 31, 32, 33. Periodically (e.g., daily or weekly), the IPSP34 transfers funds to each merchant 31, 32, 33 representative of the amount of tokens spent at each merchant's website. In one embodiment of the invention, the ASP35 manages electronic wallet accounts and distributes payments from the IPSP34 to participating merchants 31, 32, 33.

In addition to facilitating transactions between merchants and customers, the electronic wallet system may also protect the privacy of customers according to embodiments of the present invention. For example, when a customer conducts a transaction with a merchant, the merchant will not directly know the identity of the customer because the customer uses a prepaid electronic wallet account and the merchant will not query the customer for other information than that associated with the customer's electronic wallet account. The merchant only knows the customer's e-wallet account and conducts all transactions directly with the customer's e-wallet account.

Further, according to an embodiment of the present invention, the privacy of a customer can be protected by using the authentication system. For example, according to one embodiment of the invention, the financial transaction system 100 may be extended to a verification system that provides the merchant with a unique personal identification number, such as a badge, that identifies the customer. Thus, the customer is registered with the authentication system, which provides the merchant with a level of assurance that the customer is valid. Thus, the identity of the customer is protected and the merchant has certain information to transact with the customer without the need to query the customer for other information than the customer's token.

Other embodiments of the invention or appropriate variations and modifications to the above-described embodiments will become apparent to those skilled in the art from the disclosure and teachings of the above specification and drawings. Therefore, it is to be understood that the invention is not limited to the specific embodiments described in the specification, and that other embodiments and modifications and variations of the invention are intended to fall within the scope of the appended claims. Furthermore, although specific terms are employed in the specification, they are used in a generic and descriptive sense only and not for purposes of limitation.

Claims (13)

1. A fraud prevention system for identifying a potentially fraudulent online transaction received from a customer for an online merchant, comprising:

a processor configured to execute a fraud prevention module, the fraud prevention module configured to:

evaluating an online transaction received from a customer using two or more fraud filters, the two or more fraud filters selected from two or more of:

(1) identifying whether a location at which the customer is located, identified by an internet protocol address assigned to a computing device used by the customer, is a high fraud location;

(2) identifying whether the location of the customer identified by the customer's internet protocol address places a limit on the number of credit cards, the size of the purchase, or the number of purchases allowed;

(3) identifying a discrepancy between an area identified by a location of a bank that issued a credit card for the online transaction and a location of the customer identified by the customer's internet protocol address;

(4) identifying a discrepancy between the area identified by the customer's internet protocol address and the area provided by the customer; or

(5) Identifying a discrepancy between an area identified by where the customer is registered the telephone number and the customer's location identified by the customer's internet protocol address;

(6) comparing the internet protocol address assigned to the computing device used by the customer with the list of internet protocol addresses of the one or more known gateway devices to determine whether the internet protocol address assigned to the computing device is on one of the list of internet protocol addresses of the one or more known gateway devices;

in response to determining that the internet protocol address assigned to the computing device is on one of the list of internet protocol addresses of the one or more known gateway apparatuses:

requesting information from the gateway device to identify a second location associated with the computing device by providing the gateway device with an internet protocol address, a website on which the transaction is conducted, and a time and date of the transaction; and

receiving information identifying a second location associated with a user computing device;

in response to the information failing to identify the second location associated with the computing device, identifying the IP address as being unrecognizable and restricting further processing of the request; and

the processor is arranged to execute a fraud prevention module to identify the transaction as potential fraud in response to one or more fraud filters (1) - (6) employed by all online transactions.

2. The system of claim 1, wherein in response to the transaction being identified as potentially fraudulent, the processor is configured to execute the fraud prevention module to store information associated with the transaction in a fraud database.

3. The system of claim 1, wherein the one or more fraud filters are selected based on a location of the merchant.

4. The system of claim 1, wherein the one or more fraud filters are selected based on a location of the customer.

5. The system of claim 1, wherein the one or more fraud filters are selected based on a location of the bank.

6. A fraud prevention method for identifying a potentially fraudulent online transaction received from a customer for an online merchant, comprising:

evaluating an online transaction received from a customer using two or more fraud filters, the two or more fraud filters selected from two or more of:

(1) identifying whether a location identified by the customer's internet protocol address where the customer is located is a high fraud location;

(2) identifying whether the location of the customer identified by the customer's internet protocol address places a limit on the number of credit cards, the size of the purchase, or the number of purchases allowed;

(3) identifying a discrepancy between an area identified by a location of a bank that issued a credit card for the online transaction and a location of the customer identified by the customer's internet protocol address;

(4) identifying a discrepancy between the area identified by the customer's internet protocol address and the area provided by the customer; or

(5) Identifying a discrepancy between an area identified by where the customer is registered the telephone number and the customer's location identified by the customer's internet protocol address;

(6) comparing the internet protocol address assigned to the computing device used by the customer with the list of internet protocol addresses of the one or more known gateway devices to determine whether the internet protocol address assigned to the computing device is on one of the list of internet protocol addresses of the one or more known gateway devices;

in response to determining that the internet protocol address assigned to the computing device is on one of a list of internet protocol addresses of one or more known gateway devices:

requesting information from the gateway device to identify a second location associated with the computing device by providing the gateway device with an internet protocol address, a website on which the transaction is conducted, and a time and date of the transaction; and

receiving information identifying a second location associated with a user computing device;

in response to the information failing to identify the second location associated with the computing device, identifying the IP address as being unrecognizable and restricting further processing of the request;

the transaction is identified as potentially fraudulent in response to one or more fraud filters (1) - (6) employed by all online transactions.

7. The method of claim 6, wherein information associated with the transaction is stored in a fraud database in response to the transaction being identified as potentially fraudulent.

8. The method of claim 6, wherein the one or more fraud filters are selected based on a location of the merchant.

9. The method of claim 6, wherein the one or more fraud filters are selected based on a location of the customer.

10. The method of claim 6, wherein the one or more fraud filters are selected based on a location of the bank.

11. A fraud prevention system for identifying potentially improper online transactions received from a customer for an online merchant, comprising:

a processor configured to execute a fraud prevention module, the fraud prevention module configured to:

receiving a request to conduct an online transaction between a customer and an online merchant on a website;

automatically detecting an internet protocol address assigned to a computing device used by a customer to conduct an online transaction;

in response to detecting the internet protocol address:

searching one or more databases storing a list of internet protocol addresses of one or more known gateway devices; and

comparing the internet protocol address assigned to the computing device with one or more lists of internet protocol addresses of known gateway devices to determine whether the internet protocol address assigned to the computing device is on the list of internet protocol addresses of one or more known gateway devices;

in response to determining that the internet protocol address assigned to the computing device is on the list of internet protocol addresses of the one or more known gateway apparatuses:

requesting information from the gateway device to identify a second location associated with the computing device by providing the gateway device with an internet protocol address, a website on which the transaction is conducted, and a time and date of the transaction; and

receiving information to identify a second location associated with a computing device of a user;

in response to the information failing to identify the second location associated with the computing device, identifying the IP address as being unrecognizable and restricting further processing of the request; and

in response to the IP address being identified as unrecognizable, information associated with the online transaction is stored in an improper transaction database.

12. The system of claim 11, wherein in response to the request being identified as potentially improper, the processor is configured to execute a fraud prevention module to deny the online transaction between the customer and the online merchant.

13. A fraud prevention method for identifying a potentially improper online transaction received from a customer for an online merchant, comprising:

receiving a request to conduct an online transaction between a customer and an online merchant on a website;

detecting an internet protocol address assigned to a computing device used by a customer to conduct an online transaction;

in response to detecting the internet protocol address:

searching one or more databases storing a list of internet protocol addresses of one or more known gateway devices; and

comparing the internet protocol address assigned to the computing device with one or more lists of internet protocol addresses of known gateway devices to determine whether the internet protocol address assigned to the computing device is on the list of internet protocol addresses of one or more known gateway devices;

in response to determining that the internet protocol address assigned to the computing device is on the list of internet protocol addresses of one or more known gateway apparatuses,

requesting information from the gateway device to identify a second location associated with the computing device by providing the gateway device with an internet protocol address, a website on which the transaction is conducted, and a time and date of the transaction; and

receiving information to identify a second location associated with a computing device of a user;

in response to the information failing to identify the second location associated with the computing device, identifying the IP address as being unrecognizable and restricting further processing of the request; and

in response to the IP address being identified as unrecognizable, information associated with the online transaction is stored in an improper transaction database.