JP5592428B2 - System and method for conducting financial transactions over a network - Google Patents

Description

  In general, if a customer wants to use a payment card (eg, credit card or debit card) for a business partner (on the Internet or otherwise), this business partner will be electronically authorized to the successor bank Send a request. The successor bank pays this electronic authorization request via the card issuer network (eg, visa, mastercard, American Express, or private card issuer network) to the issuing bank (ie, customer). Give it to the bank or financial institution that issued the card. The issuing bank must have sufficient credit available to the customer, not paying off payments, and all information provided (eg, card number, card verification value number, And the cardholder details) are correct. The issuing bank then sends an electronic message authorizing payment over the card issuing company network to the succeeding bank, which sends the electronic message to the customer. The business partner accepts this authorization message as evidence of future payments by the issuing bank. The actual transfer of funds occurs at a later stage called payment processing.

  Transactions with payment cards that occur over the Internet or other networks involve the danger that cardholders and business partners are not usually together when the transaction occurs and therefore do not necessarily exist in face-to-face payment transactions. In addition, some e-commerce departments, such as gambling and adult entertainment, have an additional emphasis on the system's requirements to make payment card transactions reliable and to prevent fraud and other misuse. Public interest is growing.

  Various embodiments of the present invention help (1) process payment transactions more reliably, (2) protect customers and banks against fraudulent transactions, money laundering, and underage gambling, And (3) more to the e-commerce department to help limit other fraud in the area of e-commerce that proves to pose special risks such as Internet games, travel, and customers purchasing electronic goods. Provide safe financial transactions. To achieve the above goals, various embodiments of financial transaction systems (1) establish operations and transaction processing protocols for business partners, Internet payment service providers, successor banks, and card schemes, And (2) an automated system is provided to monitor and reliably process payments and financial transactions. Two or more of the various embodiments described herein can be combined to provide a system or method that meets one or more of these goals.

  In accordance with various embodiments of the present invention, a system is provided for processing financial transactions with online trading partners. The system (1) receives a request to transfer funds from a customer's account to an online trading partner, and (2) responds to an operation to receive a request to transfer the funds to trade at least a portion of the funds online. In response to allocating to the previous escrow account and (3) allocating a portion of the funds to pay to the online business partner's escrow account, a shorter predetermined period or receipt cancellation or refund request is made by the system A payment service provider module configured to store a portion of the allocated funds in an escrow account until received. Further, in one embodiment, the request is received from a trading partner computing device that communicates with a payment service provider module over a network.

  In one embodiment, the payment service provider module is further configured to periodically generate a reconciliation report for each online account. This match report lists the transfer requests received and the portion of funds allocated to the escrow account. In another various embodiment, the payment service provider module receives a deposit cancellation request or refund request for funds previously transferred from the customer's account to the customer and receives a deposit cancellation request or refund request. In response, further configured to provide funds stored in the escrow account in response to this deposit cancellation request or refund request.

  In yet another embodiment, the system also includes a fraud prevention module configured to apply one or more fraud detection filters to the request. The fraud detection filter includes: (1) a first location associated with a customer account compared to a second location associated with a customer computing device used to send a request to an online account; If the location is outside the first predetermined acceptable distance of the second location, the request is marked as potentially fraudulent, and (2) a second associated with the customer's email address. If the third position is compared to the second position and the third position is outside the second predetermined allowable distance of the second position, the request is marked as potentially incorrect. And (3) comparing a fourth position associated with the customer's billing address for the customer's account with the second position, wherein the fourth position is a third predetermined value of the second position. This request is potentially fraudulent if it is outside an acceptable distance. And (4) comparing the customer identification number with a list of persons prohibited from conducting financial transactions, and if the customer identification number matches one of the persons on the list, this The ability to mark the request as potentially fraudulent, and / or (5) compare the customer account identification number with the list of accounts prohibited from conducting financial transactions, and If the identification number matches one of the accounts in the list, the request can include a function to mark it as potentially fraudulent.

  In accordance with various embodiments of the present invention, a method is provided for funding a refund request received from a customer. This method includes: (1) providing an escrow account to a business partner (eg, an online business partner) that is funded by the proportion of funds paid to the business partner from one or more accounts associated with one or more customers; Using the funds stored in the escrow account, and (2) receiving a refund request for a payment previously made to the customer from an account associated with a particular customer; And funding the refund request. In one embodiment, the step of funding this refund request is performed without discussion. Further, according to various embodiments, the refund request is a deposit cancellation request or a refund request.

  Moreover, in yet another embodiment, the method includes a portion of funds in the escrow account in response to a portion of the funds being stored in the escrow account for a specific period (eg, at least 6 months). The step of transferring the amount to the customer is also included. In another embodiment, the method further includes (1) reducing the proportion of funds that the account pays to the escrow account in response to a decrease in the number of refund requests received by the account over a particular period of time. And (2) increasing the ratio of funds that the business partner pays to the escrow account in response to an increase in the number of refund requests received by the business partner over the specified time period. In yet another embodiment, the method includes utilizing one or more fraud detection filters configured to identify potentially fraudulent refund requests for the refund request. These fraud detection filters are operated by a fraud prevention module executed on a computer readable medium according to one embodiment of the present invention.

  According to various embodiments of the present invention, (1) receiving a refund request for a payment previously made to a customer from an account associated with a customer; and (2) stored in an account associated with the customer. A method of funding a refund request for a customer is provided, the method comprising: funding a refund request for the customer without discussing from the funded funds. This refund request may be a deposit cancellation request or a repayment request according to various embodiments. Further, according to one embodiment, a refund request is received from a financial institution that holds an account associated with the customer, and funds for the refund request are paid to the financial institution that holds the account associated with the customer. .

  In accordance with various other embodiments of the present invention, an anti-fraud system is provided for identifying potentially fraudulent online financial transactions received from customers for online merchants. The fraud prevention system includes a fraud prevention module configured to use the one or more fraud detection filters described above for each of one or more financial transactions received from one or more customers. Is included. Further, in various embodiments, the fraud detection filter includes (1) comparing information related to one or more subsequent financial transactions with financial transactions stored in the fraud database. Potentially if each customer's account, customer identification number, or customer billing address for one or more subsequent financial transactions matches any of the financial transactions stored in the fraud database The ability to mark one or more subsequent financial transactions as fraudulent, and (2) comparing the first position to the third position, the first position being the first of the third position Also included is the ability to mark this financial transaction as potentially fraudulent if it is outside a predetermined acceptable distance. Further, in embodiments where the second location includes a country, the fraud detection filter compares the second location with a list of countries that are prohibited from conducting financial transactions with the business partner, and the second location. If the is on the country list, it further includes a function that is prohibited from conducting financial transactions.

  In another embodiment, the list of accounts that are prohibited from conducting financial transactions is a list of stolen accounts. In yet another embodiment, the first location is a location associated with a financial institution that manages the customer's account. And in another embodiment, the first location is the billing address associated with the customer's account. According to various other embodiments, the first location, the second location, the third location, and the fourth location may be by country, province, state, region, city, or one or more zip codes. It can be a designated postal area. Further, in one embodiment, the list of persons and / or the list of accounts is issued by a government authority.

  Further, in one embodiment of the present invention, the fraud detection filter is selected based on the business partner's address. In another embodiment of the invention, the fraud detection filter is selected based on the second position. In yet another embodiment of the invention, the fraud detection filter is selected based on the first position.

  In another embodiment, the system further comprises a module for a payment service provider configured to receive a refund request for the customer, the fraud prevention module requesting a refund associated with the online customer Further configured to compare with a list of personnel, managers, or owners. If the customer is on the list of managers, staff, or owners, the fraud prevention module marks this refund request as potentially fraudulent.

  According to yet another embodiment of the present invention, the financial transaction is a gambling payment request, and the fraud prevention module provides an account identification number specified by the customer to receive payment from the customer, and places a wager on the customer. It is further configured to compare with the account identification number used by the customer to enter. If the identification number of the account designated to receive payment does not match the identification number of the account used to place the wager on the account, the fraud prevention module will consider this as potentially fraudulent. Mark a refund request. In yet another embodiment, the anti-fraud module is further configured so that the amount specified in the refund request is not transferred to the designated account to receive the refund. In another embodiment, the account designated to receive the refund request is associated with the first payment card, the account used to place a wager on the merchant is associated with the second payment card, and The fraud prevention module is further configured to compare the first payment card with the second payment card. If the first payment card does not match the second payment card, the fraud prevention module marks the refund request as potentially fraudulent.

  According to various embodiments of the present invention, a system is provided for monitoring a customer's forced spending behavior. The system includes a processor and memory, and (1) information in the memory, including the total amount of funds associated with each of one or more requests from a customer, for the processor to (1) conduct financial transactions with a customer. And (2) receive a new request containing a new amount of funds to conduct a financial transaction with a business partner, and (3) upon receipt of this new request, repair the total amount of funds stored in memory. (4) compare the total amount of funds and the total amount of funds in the new request with a predetermined acceptable limit, and (5) if this total exceeds a predetermined acceptable limit, It is configured to notify one or more of the associated payment sources or business partners that have exceeded a predetermined acceptable limit. In certain embodiments, the information stored in the memory further includes data for which each request has been received by the trading partner, and the amount of funds that the processor has stored in the memory within a specific time period. And the sum of the amount of funds in the new request is further configured to compare to a predetermined acceptable limit.

  In accordance with various other embodiments of the present invention, another system for monitoring a customer's forced gambling behavior is provided. This system is similar to the system described above, but the processor repairs the total amount of funds stored in memory for the type of financial transaction in the new request, and the total amount of funds and the new request. Is further configured to compare the sum of the amount of funds in the list with a predetermined acceptable limit associated with the type of financial transaction in the new request. In various embodiments of the invention, the type of transaction may be a request to transfer funds from an account associated with a customer to a customer, or a request to place a wager using funds previously transferred to a customer. it can. Further, in one embodiment, the request and the new request are received by a computer device associated with the business partner over one network from one or more computer devices associated with the customer. In certain embodiments where the information stored in the memory includes the date of the request received by the trading partner, the processor may include the total amount of funds requested by the customer within a particular time period and the new request It is further configured to compare the sum of the amount of funds to a predetermined acceptable limit. In another embodiment, the processor is further configured so that no new request is processed if this sum exceeds a predetermined acceptable limit.

  According to various embodiments of the present invention, a third system for monitoring a customer's forced spending behavior is provided. This system is similar to the first system described above, but the information related to the request includes the date that the customer received the request. The processing of this third system repairs the total number of transactions stored in memory within a predetermined period of time, compares the total number of transactions with a predetermined acceptable limit, and the total number of transactions is a predetermined acceptable It is further configured to notify one or more of a customer, a payment source associated with the customer, or a business partner whose limit has been exceeded if the limit is exceeded.

  In various embodiments of the present invention, a tax accounting system is provided for financial transactions conducted with online business partners. The tax accounting system includes a memory and a processor configured to store a corresponding tax rate for each of one or more tax types and one or more tax jurisdictions. The processor (1) receives information from a customer related to a financial transaction made to an online customer, and (2) receives information related to a financial transaction, and receives one or more taxes related to the financial transaction. A memory to identify the jurisdiction and (3) identify one or more tax jurisdictions associated with a financial transaction and determine whether one or more tax types are associated with one or more tax jurisdictions. (4) If it is determined that one or more tax types are associated with one or more tax jurisdictions, it will be related to the financial transaction to determine the amount of tax payable. Apply the corresponding tax rate to each of the one or more tax types for the information, and (5) once the tax amount to be paid is determined, the tax amount to be paid to one or more relevant tax authorities It is configured to transfer money. In various embodiments, the tax jurisdiction is related to the address of the online business partner, the location of the customer, and / or the location of the computing device that the customer uses to conduct financial transactions.

  In yet another embodiment, the processor is further configured to transfer the amount to one or more associated tax authorities via an electronic funds transfer system. In another embodiment, the processor is further configured to store in memory the amount transferred to one or more associated tax authorities using the tax amount payable and financial transaction information over a specified period of time. . In yet another embodiment, the processor is specifically configured to generate an accounting report for each of the one or more associated tax authorities, which is the tax amount that the associated tax authority is liable to pay. , Tax amounts transferred to the relevant tax authorities, and at least some of the information related to financial transactions paid to the relevant tax authorities.

  According to various other embodiments of the present invention, a system is provided for processing a financial transaction made to an online customer. The system includes a payment service provider module that includes (1) a first location associated with a customer location and a second location of the computing device that generated the request. (2) When this request is received, the first position, the second position, and the address of the online business partner are transferred to the online business partner. (3) if the first location, the second location, and the address of the online account match the location in the location list, one or more supervisors Determining whether to restrict the transfer of funds from the customer's account to the online account at the location, the second position, or the address of the online account, and (4) one One or more customers, business partners, or financial transactions if the above supervisory authority decides to regulate the transfer of funds to the online business partner at the first location, second location, or online business partner address The bank associated with the customer's account associated with is configured to notify one or more types of regulations governing the transfer of funds. The type of regulation includes prohibiting one or more movements, restricting movement, or taxing movement. In one embodiment, the second location is associated with an Internet protocol issued to the computing device that generated the request.

  According to various embodiments of the present invention, a second system is provided for processing a financial transaction made to an online customer. The system includes a payment service provider module that includes (1) a first location associated with a customer location and a second location of the computing device that generated the request. A request to conduct a financial transaction between an account and an online account (for example, a request to enter a gambling wager for an online account, a request to transfer funds to an online account, or an online account (2) a request for payment generated for one or more gambling bets entered against (2) upon receipt of this request, the first position, the second position, and the online account's Compare the address to a list of locations that define financial transactions made to online suppliers, and (3) first location, second location, or supplier If the address matches a position in the list of positions, one or more supervisors regulate the financial transactions made to the online account at the first position, the second position, or the address of the online account And (4) one or more customers if one or more supervisory bodies decide to regulate financial transactions at the first location, second location, or business address Configured to notify the business partner, or the bank associated with the customer's account associated with the financial transaction, of the type of regulation under which the financial transaction is managed.

  In one embodiment, the payment service provider module determines that one or more supervisory bodies regulate financial transactions with an online business partner at a first location, a second location, or an online business partner address. In response to being made, the transaction is further configured to prohibit the financial transaction from being performed with the business partner. In yet another embodiment, the payment service provider module is a financial transaction conducted by one or more supervisors with an online account at a first location, a second location, or an online account address. Is further configured to notify a bank associated with one or more online business partners or customer accounts.

  Various embodiments of the present invention have thus been described in general terms, and now reference is made to the accompanying drawings. These drawings are not necessarily drawn to scale.

1 is a high level block diagram of a financial transaction processing system in accordance with various embodiments of the invention. FIG. FIG. 6 illustrates various contractual relationships in a financial transaction processing system according to various embodiments of the present invention. 1 is a schematic diagram of a computer device according to one embodiment of the invention. FIG. FIG. 6 is a schematic diagram of a computer device according to another embodiment of the present invention. 1 is a schematic diagram illustrating a financial transaction processing system according to various embodiments of the invention. FIG. FIG. 6 is a block diagram of a supplier module according to various embodiments of the invention. 2 is a block diagram of an IPSP module according to various embodiments of the present invention. FIG. FIG. 4 is a block diagram of an anti-fraud submodule according to various embodiments of the invention. 6 is a flowchart of an anti-fraud submodule according to various embodiments of the invention. 2 is a block diagram of an ASP module according to various embodiments of the invention. FIG. 6 is a flowchart of a delegation transaction process according to various embodiments of the present invention. 6 is a flowchart of a delegation transaction process according to various embodiments of the present invention. 6 is a flowchart of a settlement transaction process according to various embodiments of the present invention. 6 is a flowchart of a settlement transaction process according to various embodiments of the present invention. 7 is a flowchart of a deposit cancellation transaction process according to various embodiments of the present invention. 6 is a flowchart of a customer payment transaction process according to various embodiments of the present invention. 6 is a flowchart of a delegation transaction request process according to an embodiment of the present invention. 6 is a flowchart of a settlement transaction request process according to one embodiment of the present invention. 4 is a flowchart of a method for monitoring forced spending behavior according to one embodiment of the invention. 2 is a flowchart of a method for monitoring forced gambling operations according to one embodiment of the present invention. 4 is a flowchart of a method for determining taxes that are payable on a financial transaction, in accordance with one embodiment of the present invention. 4 is a flowchart of a method for identifying financial transactions that are illegal or subject to regulation, in accordance with one embodiment of the present invention.

  Various embodiments of the present invention will now be described more fully with reference to the accompanying drawings. These drawings illustrate some, but not all, embodiments of the present invention. Indeed, the invention may be embodied in many different forms but should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will satisfy applicable legal requirements. Like reference numbers refer to like elements throughout.

Overview Overall, various embodiments of the present invention (1) process payment transactions more reliably and (2) protect customers and banks against fraudulent transactions, money laundering, and underage gambling. And (3) helping to limit other fraud in the area of e-commerce that proves to pose special risks, such as Internet games, travel, and customers purchasing electronic goods. An improved financial transaction processing system for the commerce sector is provided. To achieve the above goals, various embodiments of the financial transaction system (1) establish operations and transaction processing protocols for trading partners, Internet payment service providers, successor banks, and card mechanisms, and (2) An improved automated system for monitoring and processing payments and related financial transactions is provided.

  For example, in various embodiments of the present invention, a rolling reserve escrow account is established for each account, and funds are allocated in a manner that reduces the risk of loss to the successor or issuer bank. It is done. For example, according to one embodiment, the risk of loss is reduced by ensuring that sufficient funds are available to process a refund (eg, deposit cancellation and refund) request received by a business partner. The According to one embodiment, a certain percentage of funds paid to a business partner is saved and transferred to an escrow account for a certain period (eg, 6 months, 1 year, or 3 years), and the funds are in that period. If not used, the funds are sent back to the customer. Since the money funded in the revolving escrow account is taken from the potential profit of the business partner, it would be unattractive to use the business partner's function for money laundering plans. Further, according to various embodiments, the position that a business partner can discuss withdrawing a withdrawal request is limited, so that an acceptable position to compete is a risk of loss to the successor or issuing bank (e.g. ) Transactions are rarely increased. In another embodiment, the business partner is not allowed to compete for a withdrawal request from any position. Thus, according to various embodiments, a revolving escrow account ensures a funding source to process refund requests, reduces the risk of loss to the customer, and allows the customer to engage in online financial transactions. Sex is increased. In addition, when a business partner funds a refund request, the risk of loss to the successor bank and the issuing bank is reduced, and there are more favorable trading conditions for the business partner (for example, lower transaction fees or lower deposit cancellations). Charge).

  As another example, in various embodiments of the present invention, participants in a financial transaction system require each other to follow a regional supervisory authority. For example, in one embodiment, if a business partner is out of compliance, an Internet payment service provider (which will be described in more detail later), a successor bank, and a card mechanism conduct business with that business partner. I will reject it. In another method, in one embodiment, participants who do not comply with the rules are fined. In addition, customers may refuse to do business with business partners who do not comply with the rules. By establishing this protocol, the financial trading system is designed to provide market incentives for participants who follow local supervisors.

  Participants in the financial transaction system include online customers, online business partners, Internet payment service providers (IPSPs), successor banks, issuing banks, or card mechanisms, according to various embodiments of the present invention. This IPSP operates between the business partner and the succeeding bank, provides services related to payment to the business partner, and is an interface between the business partner on the network and the succeeding bank. In addition, the IPSP contracts with an accounting service provider (ASP) to provide accounting management services related to payment services that the IPSP provides to business partners.

  FIG. 1 illustrates a high level schematic diagram of how various participants are tied together, according to various embodiments of the present invention. For example, participants can exchange transaction information electronically over a network (eg, the Internet, a private network, or a private LAN network). In particular, the transaction information includes an authorization request from the customer to transfer the money from the account associated with the customer's payment card to the customer's account, the transfer of money from the customer's account to the customer's account. An authorization message from the issuing bank to authorize, a refund (eg, withdrawal or refund) request from the issuing bank that requires the money to be transferred from the customer's account to the customer's account, and a specific period (eg, 24 hours) , 48 hours, or 1 week) for each transaction processed for each transaction.

  The embodiments described above use a payment card (eg, debit card, credit card, prepaid card, or proximity card) associated with an account to purchase goods and services from an online business partner. However, in various other embodiments, other types of payment modes can be used to purchase. For example, another payment mode may use a payment token associated with the account (eg, a physical or electronic token) or a number associated with the account (eg, access to the account number and the account). To use a password). Another payment mode includes an operation that authorizes payment by using biometric data associated with the account, such as iris scan, fingerprint, and voice recognition. Payment may be authorized by a combination of account number and one-time password. This one-time password is provided by token or via telephone, email, or short message service (“SMS”).

  As briefly described above, this financial transaction system according to various embodiments is adapted to (1) operate and process protocols for participants and (2) process financial transactions with a high degree of security. Provide an adapted automatic monitoring and processing system (eg, computer software and / or hardware). These protocols and automated systems function to protect customers and participants from fraudulent transactions and other misuses that can be dangerous in electronic commerce. Various examples of protocols executed by the system are described in detail in Section A below, and various embodiments of automated systems are described in Section B below. The typical flow of various transactions processed through the financial transaction system is described in more detail in Section C.

A. Exemplary Protocol Various embodiments of this financial transaction system provide operational and processing protocols for participants. According to various embodiments, these protocols prevent organized laundering and money laundering plans that use transactions with business partners, reducing the risk of fraudulent and unauthorized transactions generally associated with online financial transactions. As well as reducing the risk of loss to the successor and issuing banks and increasing the likelihood of complying with government or local regulations. For example, according to various embodiments of the present invention, participants need to be able to demonstrate compliance with local or competent supervisory authorities and for a specific period of time (eg, 2 years, 3 years, or It is necessary to maintain an inspectable record of transactions processed in 5 years). In addition, the protocol requires each participant to demonstrate compliance with local legal requirements before signing a contract with another participant, and the protocol requires that the participant and other participants Require regular verification that you are in good standing with a supervisory authority. Various exemplary protocols established for trading partners and IPSPs are described below.

Business Partners According to various embodiments of the present invention, business partners are required to disclose the identity of company managers, employees, and beneficial shareholders, and to report any changes to IPSP. Is done. Requesting that this list be provided, and comparing this list to a list of persons and entities suspected of being related to organized crimes, may mean that organized crime associates are money laundering or other Useful to prevent the use of a business partner for illegal purposes.

  Further, in accordance with various embodiments of the present invention, a business partner may take one or more actions to help reduce the risk of loss from fraudulent transactions to successor banks, issuing banks, and customers. Required. For example, according to various embodiments, a business partner may (1) demonstrate compliance with all relevant legal requirements, (2) be fined if any contractual obligations are breached. (3) use address verification, age verification, and identity verification software on the supplier's computer device to verify payment information and customer information provided during online transactions; 4) Perform initial fraud checks on received payments and customer information, and then perform random or periodic checks thereafter, or (5) Customers accessing the system using IP addresses; Or, be wary of customers who provide billing destinations related to jurisdictions where transactions are considered fraudulent.

  Furthermore, according to various embodiments, it has been clarified that a business partner mitigates the risk of unauthorized use in connection with the business of the business partner, i.e., conducts business with a business partner when there is unauthorized use. It is required to implement a protocol that mitigates social impact (eg, forced spending if the customer is an online game merchant or adult entertainment provider). For example, business partners provide advice and support resources on the social impact of their business (eg, free phone numbers for websites that provide helpline and useful information, or contact information for counselors) As required. Further, according to one embodiment, the merchant provides the customer's name and toll-free phone number to the customer's payment card statement for the customer to call customer service and inquire about the transaction. As required. According to various embodiments of the present invention, customer service representatives can utilize 24/7.

IPSP
In accordance with various embodiments of the present invention, IPSP can help prevent organized crime groups and the like from using a business of a business partner for money laundering, and also to various participants. In order to reduce the risks associated with online financial transactions, it is required to implement one or more of the following safety measures. In other words, these safety measures are: (1) setting the above-described rotation-preserving escrow account for each supplier that processes the refund request, and (2) monitoring the transaction to identify suspicious behavior. (3) monitor the number and amount of transactions per payment card base; (4) continue transactions with each customer (or website) in a separate flow for tracking and auditing. (5) Periodically (e.g., 2 or 10 seconds) transaction information to create an audit trial and store transaction information over a specified period (e.g., 1 year, 2 years, or 5 years) (6) Confirm the identity of the cardholder, (7) Request the business partner to disclose the company administrator and beneficial shareholders to IPSP, (8) Internet Restricting the payment of prize money from cardholders to cardholders, and examining payee names against applicable sanction lists (eg, “specially designated national lists” in the United States); 9) require business partners to obtain permission under appropriate local laws and regulations, and to maintain good financial and legal conditions; (10) violate contractual obligations; Punish merchants found to be found (for example, by terminating contracts or penalizing merchants), (11) several Tier 1 (Tier) operating in well-regulated jurisdictions 1) Use a successor bank to be recognized by those banks; (12) Require suppliers to implement methods, procedures and standards in order to retain secure cardholder information (E.g., certified by VISA's Account Information Security ("AIS") program), and (13) Financial Action Task Force on Money Laundering recommendations (e.g. , Www.FATF-GAFI.org) (eg, “Anti-Money Laundering / Combating Terrorist Financing Methodology (with FATF 40 + 9 incorporated) published by the International Monetary Fund attached to Appendix A) ) "). Further, in various embodiments, to store information regarding transactions processed by IPSP that have been found to be fraudulent or determined to be fraudulent, the IPSP can use the fraudulent database shown in FIG. 42 is held. According to one embodiment, IPSP allows participants to use this fraudulent database when processing transactions, resulting in loss to issuing and succeeding banks, trading partners, and customers. Can be further reduced. The IPSP can manage its own account and fraud database, arbitrate transactions for processing, and issue a match report to a business partner, but according to another embodiment, one or more IPSPs You can contract with an ASP to provide these services.

  In addition, an exemplary protocol according to one embodiment of the present invention is that IPSP creates a separate business entity (eg, SG1, SG2, SG3, etc.) for each customer, and these business entities are IPSP and / or Or, under the direction of the ASP, request to operate to manage funds received for a specific business partner associated with the business entity. This is explained in more detail in connection with FIG. According to various embodiments, this business form separates the operations of each customer. Furthermore, according to various embodiments, this business form is a legitimate form that ensures fair and objective control of financial transaction systems and escrow funds held to protect customers. Is provided.

Successor Bank According to various embodiments of the present invention, an exemplary protocol may be used by a successor bank to implement one or more of the following security measures to reduce risks associated with online transactions to issuing banks and customers. Request to run. That is, these safety measures include: (1) monitoring online account credit activity (eg sponsored by VISA) to ensure that customers receive winnings or credits from their counterparts on their payment cards. Cardholder funds transfer (CFT pilot and money flow pilot sponsored by MasterCard), (2) all card scheme regulations are IPSP and business partners (3) Ensure that transaction information has the correct data elements as directed by the card organization and issuing bank, and (4) Ensure that IPSP complies with applicable regulatory systems. That is.

Agreement Between Participants According to various embodiments of the present invention, one or more system protocols are incorporated into an agreement between participants to ensure adherence to established protocols. For example, FIG. 2 illustrates a schematic diagram of contractual relationships between participants in accordance with various embodiments of the present invention. In particular, the successor bank 36, the IPSP 34, and each of the business partners 31, 32, 33 can participate in a three-way processing contract 45. This three-party processing agreement shows each party's obligations as to how to process the transaction. This agreement 45 provides each party with a good relationship with the local supervisory authority, providing an updated list of employees, managers, and beneficial shareholders to other parties, Requires verification and fraud investigation, and storage of transaction information for a specified period of time (eg, 1 year, 3 years, 5 years). Furthermore, according to one embodiment, the agreement 45 can comprise one or more places where the business can discuss refund requests. According to another embodiment, the agreement 45 may define a charge that can be charged to the business partners 31, 32, 33 for failure to pay.

  Further, the successor bank 36 and the bank 4 can join the trust agreement 47. This trust agreement 47 performs certain fraud checks that the IPSP should perform on the transaction data when the IPSP requests settlement for each customer (eg, daily or weekly).

  The ASP 35 and the business partners 31, 32, 33 can subscribe to the escrow contract 49. This escrow agreement 49 shows how the ASP manages the rotationally stored escrow account for the business partner (eg, the percentage of funds that are withdrawn from the escrow account, that money is stored in the escrow account. Period or form of consensus report).

  Further, the ASP 35 and the IPSP 34 can subscribe to the service contract 43. This service agreement 43 indicates each party's obligations related to the accounting services provided to the IPSP by the ASP (for example, the format and accessibility of the data exchanged between the ASP and the IPSP, the ASP to the IPSP 34). Summary report types and formats created for or for IPSP 34, calculation of fees payable to one or more participants, or approval procedures for approving matching reports to business partners). In addition, in one embodiment, ASP 35 is required by contract 43 to respond to inquiries from trading partners 31, 32, 33 regarding transactions processed by ASP 35 on behalf of IPSP 34 or IPSP 34. Further, in another embodiment, ASP 35 identifies (a) all transaction data processed by ASP 35 on behalf of IPSP 34 that is associated with a withdrawal request, and (b) identifies this identified data. Transfer to customer 31, 32, 33 to confirm what, if any, another action that customer 31, 32, 33 wishes to perform in connection with a withdrawal request Required.

B. Automated System for Monitoring and Processing Transactions As will be apparent to those skilled in the art, the present invention is embodied as a method, transaction processing system, or 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 (eg, computer software) embodied in the storage medium. More specifically, the present invention can take the form of computer software running on the web. Any suitable computer readable storage medium may be used including hard disks, CD-ROMs, optical storage devices, or magnetic storage devices.

  Based on embodiments of the present invention, with reference to block diagrams and flowcharts of methods, apparatus (ie, systems) and computer program products, the present invention is described as follows. It will be understood that each block of the block diagrams and flowcharts, and combinations of blocks in the block diagrams and flowcharts, can each be executed by computer program instructions. These computer program instructions are loaded into a general purpose computer, special purpose computer, or other programmable data processing device and executed by the computer or other programmable data processing device in a flowchart. Create a device that creates a means to perform the function specified in the block.

  The instructions of these computer programs that can cause a computer or other programmable data processing device to function in a particular way are stored in a computer readable memory and stored in a computer readable memory. It is also possible to create a product in which the stored instructions include computer readable instructions that perform the functions specified in the flowchart blocks. The instructions of the computer program are loaded into a computer or other programmable data processing device and a series of operational steps are executed on the computer or other programmable device to perform processing by the execution of the computer. Instructions executed on the programmable device may also provide steps to perform the functions specified in the flowchart blocks.

  Accordingly, the blocks in the block diagrams and flowcharts correspond to a combination of means for performing a specified function, a combination of steps for executing a specified function, and a means for program instructions for executing a specified function. Each block in the block diagrams and flowcharts and combinations of blocks in the block diagrams and flowcharts is determined by a special purpose hardware-based system that performs a specified function or step or combination of special purpose hardware and computer instructions. It will also be appreciated that it can be implemented.

  In various embodiments described herein, reference is made to the term “computer” or “computer device”. Such a computer may be, for example, a mainframe, a desktop, a notebook or laptop, a hand held device such as a data collection and storage device, or in another device such as a wireless telephone, for example. It can be an integrated processing device. In some implementations, the computer may be a “dum” terminal used to access data or processors over a network. With reference to FIG. 3A, one embodiment of a computing device that can be used to implement aspects of various embodiments of the present invention is illustrated. In FIG. 3A, a processor 1, such as a microprocessor, is used to execute software instructions to perform the defined steps. The processor is powered by the power supply 17, which also supplies power to other components when needed. The processor 1 generally communicates using a data bus 5 that is 16 or 32 bits wide (eg, in parallel). The data bus 5 is mainly used to carry data and program instructions between the processor and the memory. In various embodiments, the memory is considered a RAM or other form of main memory 2 that holds content only while it is operating. Alternatively, the memory can be a non-volatile memory 3, such as a ROM, EPROM, EEPROM, flash, or other type of memory that always holds the contents of the memory. The memory may be an auxiliary storage device 4 such as a disk storage device that stores a large amount of data. In some embodiments, the disk storage device can communicate with the processor using the I / O bus 6 instead of a dedicated bus (not shown). The auxiliary storage device can be a floppy disk, hard disk, compact disk, DVD, or any other type of mass storage device known to those skilled in computer technology.

  The processor 1 also communicates with various peripheral devices or external devices using the I / O bus 6. In various embodiments, the peripheral I / O controller 7 provides a standard interface such as RS-232, RS422, DIN, or other interface suitable for connecting various input / output devices. used. Exemplary input / output devices include a local printer 18, a monitor 8, a keyboard 9, and a mouse 10 or other common pointing device (eg, rollerball, trackpad, joystick, etc.).

  The processor 1 often communicates with an external communication network using the communication I / O controller 11, and 25, various interfaces such as data communication oriented protocol 12 such as ISDN, DSL, and cable modem can be used. The communication controller 11 can also incorporate a modem (not shown) to interface and communicate with a standard communication line 13. Finally, the communication I / O controller can incorporate an Ethernet interface to communicate via the LAN. Any of these interfaces can be used to access a wide area network such as the Internet, an intranet, a LAN, or other data communication device.

  Further, the processor 1 can communicate with the wireless interface 16. The wireless interface 16 is one of standard 3G wireless telecommunications protocols such as, for example, IEEE 802.11 protocol, 802.15.4 protocol, or CDMA2000 1x EV-DO, GPRS, W-CDMA, or other protocols. Is operatively connected to the antenna 15 for wireless communication with other devices.

  Another embodiment of a processing system that can be used is shown in FIG. 3B. In this embodiment, a distributed communication and processing architecture is shown that includes a server 20 that communicates with either a local client computer 26a or a remote client computer 26b. The server 20 mainly includes a processor 21 that communicates with a database 22 (for example, an SQL database). This database 22 can be regarded not only as the main storage device 24 but also as an auxiliary storage device. This processor also communicates with external devices, usually using an I / O controller 23 connected to the LAN 25. This LAN provides connectivity to a printer 28 and a local client computer 26a connected by a network. These devices are not necessarily placed in the same room, but can be placed in the same facility as the server. Communication with remote devices is accomplished primarily by directing data from the LAN 25 via a communication device to a wide area network 27 such as the Internet. The remote client computer 26b executes a web browser, and the remote client computer 26b transmits data to the server 20 via the LAN 25 through the wide area network 27 as necessary, thereby allowing mutual communication with the server. To be able to work. In addition, the web browser can include a user interface developed with, for example, Java Script and Microsoft.net.

  Those skilled in the art of data networks will appreciate that many other alternative technologies and architectures can be implemented and used to implement various embodiments of the present invention. The embodiment illustrated in FIGS. 3A and 3B can be modified in various ways and within the scope of the present invention.

  FIG. 4 is a computer device associated with each participant and communicating with each other over one or more networks 115 (eg, a private network, a private LAN network, or the Internet) in accordance with various embodiments of the present invention. 101-109 are illustrated. For example, according to one embodiment, the IPSP 34 is accessible to the business partners 31, 32, 33 and the successor bank 36 via the IPSP gateway 40, and the IPSP gateway 40 connects the IPSP network to the business partners 31, 32. , 33 and the successor bank 36 are connected to the network used. According to various embodiments, the IPSP gateway 40 can be fully implemented as hardware, software, or a combination of both. In one embodiment, the IPSP gateway 40 ensures the security of information transmitted to and from the IPSP 34 by selectively allowing access to the IPSP network. For example, the business partners 31, 32, 33 and the successor bank 36 having no contract relationship with the IPSP 34 are denied access to the IPSP network by the IPSP gateway 40.

  Further, according to various embodiments of the present invention, the successor bank 36 can exchange information with the issuing banks 37, 38, 39 using the card mechanism network. Examples of card mechanism networks include, but are not limited to, Visa, MasterCard, and American Express networks.

  As previously described in connection with FIGS. 3A and 3B, according to various embodiments, there is one customer 31, 32, 33, IPSP 34, successor bank 36, and issuing bank 37, 38, 39. Associated with these computer devices (eg, one or more servers, SQL servers, or web servers), and one or more of these computer devices may comprise an automated system for processing financial transactions. For example, the system 100 includes a supplier module 200 configured to operate on a supplier system 101, 102, 103, an IPSP module configured to operate on an IPSP system 104, and an ASP An ASP module configured to operate on the system 105 is provided. These modules 200, 300, 400 automate the processing functions for each participant according to one embodiment. These modules can be fully implemented as hardware, software, or a combination of both.

  Further, according to one embodiment, the ASP module 400 can be configured to operate on the ASP system 105 when the IPSP 34 contracts with the ASP 35 to provide account-related services, or In another embodiment, the ASP module 400 may be configured to operate on the IPSP system 104. Various embodiments of these modules are described in more detail below with respect to FIGS.

Supplier Module FIG. 5 illustrates a block diagram of a supplier module 200 in accordance with various embodiments of the invention. According to various embodiments, the supplier module 200 operates on the supplier's system 101, 102, 103 and automates at least some of the steps that the supplier performs to process the transaction. For example, the supplier module 200 is configured to process a permission request shown as step 202. In step 202, the business partner module 200 receives a payment request from a customer. This payment request includes some or all of the customer's name, billing address, email address, credit card number, CVV2 number, payment amount, or card issuer name. Next, this supplier module 200 verifies the format of the received payment information, such as by verifying whether the credit card number is a valid number and whether all fields are inhaled. . The vendor module 200 is further configured to compare customer information with previously stored identification numbers and passwords associated with a 3D secure software plug-in (eg, (Verification by Visa and SecureCode by MasterCard). If the format is correct, supplier module 200 generates an authorization request and sends it to IPSP system 104 for further processing.

  According to various embodiments of the present invention, the customer module 200 is also configured to perform a basic fraud check on the received transaction request, as shown in step 206. . This basic fraud check step 206, for example, compares the credit card number with a list of stolen credit card numbers, the billing address provided by the customer matches the billing address for the payment card To verify the payment, to compare the given billing address with the billing address provided when the customer first registered with the customer, or the card issuer name is the bank verification number for the card An operation of verifying that it matches (BIN) may be included. Further, the fraud checking step 206 is performed after the authorization request is sent to the IPSP (step 202) or before creating and sending the authorization request, as shown in FIG. 5 (not shown). ) In one embodiment, the fraud check step 206 is performed after the authorization request has been sent (step 202) but before an agreement with the issuing bank.

  If a potential problem is not found in the fraud check step 206, the supplier module 200 verifies the customer's age and identity, as shown in step 210. For example, the age may be verified by checking government records on cardholders such as voter registration records or driver's license records, or by electronic age and / or identity verification services (eg, UK-based GB groups It is verified by establishing a network connection with the "URU" service that it provides) and providing customer information to this service. This service, according to various embodiments, compares customer information with government or other official documents to verify public identity and age. In one embodiment, the business partner module 200 may perform the age and identity verification step 210 when the customer is establishing a new account with the business partner. The process of step 210 is repeated periodically, or at a later time randomly re-verifies the current customer's identity and age. Further, in the embodiment shown in FIG. 5, the age / identity verification step 210 is shown to occur after the fraud check step 206 and the approval request step 202. However, in another embodiment, the age / identity verification step 210 can be performed before the approval request step 202 or the fraud check step 206.

  If the customer's age and identity are not verified in the age / identity verification step 210, or if the fraud check step 206 finds a potential problem with the transaction, the supplier module 200 is in one embodiment. Thus, as shown in step 208, the customer is informed that the transaction is rejected and the IPSP is informed that the transaction should be rejected.

  Further, the customer module 200 according to various embodiments is configured to display or notify the customer of the amount spent on the customer's website for a specific period of time (eg, per session, 24 hours, or 1 week). Is done. This information allows customers to avoid compulsory behavior related to the customer's website. Moreover, the supplier module 200 is configured to allow the customer to access a transaction log for the customer maintained by the supplier. Further, the supplier module 200 is configured to establish self-regulatory guidelines, for example, for loss limits (eg, gambling transactions) or time and / or amount spent on the customer's website. .

  In order to prevent money laundering, the customer module 200 is used to prevent money laundering software (in order to inspect all transactions that exceed a selected amount (eg, $ 15,000 or $ 20,000)). For example, valid parameters are listed in “Anti-Money Laundering / Combating Terrorist Financing Methodology (with FATF 40 + 9 incorporated)” published by the International Monetary Fund attached as Appendix A. And software to be compared. Software testing includes identity verification and reconfirmation, followed by verification to the verified individual or company.

IPSP Module FIG. 6 illustrates a flowchart of an IPSP module 300 according to various embodiments of the invention. According to one embodiment, the IPSP module 300 is configured to operate on the IPSP system 104. Once the operation begins at step 302, according to one embodiment, the IPSP module 300 processes the authorization request received from the trading partner systems 101, 102, 103. Each authorization request includes payment information for a particular transaction and customer information related to the transaction, such as the customer's name, the customer's email address, and the IP address of the computing device used by the customer to initiate the transaction. It is. In accordance with various embodiments of the present invention, the IPSP module 300 then sends a permission request to the successor bank system 106 which passes the permission request to the appropriate issuing bank system 107, 108. , 109. Although described in more detail below with respect to FIGS. 9A and 9B, according to various embodiments, the IPSP module 300 can perform transactions from the issuing bank system 107, 108, 109 via the successor bank system 106. The permission message described as permitting or denying is received, and the permission message is sent to the system 101, 102, 103 of the business partner.

  According to various embodiments, at step 304, the IPSP module 300 saves the transaction information it has processed (eg, authorization request, deposit cancellation request, refund request, and settlement request). This stored transaction information is used to monitor the type and frequency of transactions for auditing purposes, per customer, per payment card, or per customer base, and to create settlement requests and respond to these settlement requests. Can be used to allocate payments for received funds. For example, authorization, withdrawal cancellation, and refund requests can be saved on a regular basis, such as every second or ten seconds, or per transaction base, such as every time the IPSP module 300 receives and processes transaction information. These requests can be stored for a period of time (eg, a day or a week or more). Further, according to various embodiments, if a business partner has one or more websites that support e-commerce, these requests are sent per business partner base (or URL (Uniform Resource Locator)). ))) Can be saved. The IPSP module 300 collects authorization requests for each business partner in a settlement request file for each business partner periodically (for example, daily or weekly), and settles the settlement request for this business partner in the form of a batch file. To the succeeding bank's system 106. This is described below in connection with step 310. The IPSP module 300 can store the grouped transaction information as a separate file for a certain period (eg, 1 year, 2 years, or 3 years).

  In various embodiments of the present invention, the IPSP module 300 is also configured to execute the fraud prevention subsystem 350. This is shown as step 306 in FIG. 6 and will be described in more detail below with respect to FIGS. 7A and 7B to confirm that the transaction needs to be settled by the system 100. For example, the payment card number is listed in 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 has a national sanctions list. ) (Eg, “Specially Designated Nationals list” in the United States), IPSP module 300 does not submit to settle the transaction. In the embodiment shown in FIG. 6, the execution of fraud prevention subsystem 350 is shown to occur after authorization request processing step 302 and transaction information storage step 304. However, according to another embodiment of the present invention, before sending the authorization request to the successor bank system 106 in step 302 or saving the transaction information in step 304, the IPSP module 300 performs step 306. be able to.

  In accordance with various embodiments of the present invention, if the anti-fraud sub-module 350 detects a potential fraud for a transaction at step 306, the IPSP module 300 may It is configured to notify the parties to the suspected fraud. This applicable party may be, according to various embodiments, a successor bank 36 (which sends a notification to the issuing bank), an issuing bank 37, 38, 39 (directly connected), a business partner 31, 32. , 33, and / or customers. Further, IPSP module 300 stores information regarding potentially fraudulent transactions in fraudulent database 42, as shown in step 312, according to various embodiments. This fraud database 42 is used by the IPSP module 300 to analyze subsequent transactions. Further, in one embodiment, the fraud database 42 can access the card issuer network and / or the successor bank to analyze received transactions. In addition, the fraud database 42 identifies one or more of the following fields: customer name, address, IP address, payment information (eg, card or account number), phone number, and previous fraud. A code or description can be included.

  As shown in step 310, if the anti-fraud sub-module 350 does not detect a potential fraud in step 306, the IPSP module 300 may create a payment request according to various embodiments. It is transmitted to the succeeding bank system 106 or the issuing bank system 107, 108, 109. This settlement request is based on the permission, deposit cancellation and refund requests received by the IPSP module 300 during a specific period (eg, one day or one week). According to one embodiment, the settlement request includes only transactions that have not been detected as potential fraud by the IPSP module 300 and the supplier module 200. Alternatively, the payment request includes one or more transactions detected as potentially fraudulent by the IPSP module 300 or the supplier module 200, but those transactions are potentially fraudulent. Are marked or flagged in the payment request.

  As described above, the IPSP module 300 executes the fraud prevention submodule 350 in step 306. An exemplary fraud prevention sub-module 350 according to various embodiments of the present invention is shown in FIGS. 7A and 7B. As shown in FIG. 7A, the fraud prevention sub-module 350 performs various steps, referred to herein as “fraud detection filters,” to detect potentially fraudulent transactions and to identify specific frauds. A combination of detection filter results or fraud detection filter group results is configured to block or flag the transaction. Steps 352-368 illustrate several fraud detection filters performed by the fraud prevention submodule 350, according to various embodiments of the present invention. FIG. 7B illustrates the steps performed by the fraud prevention submodule 350 to determine which fraud detection filter is applied to the transaction information.

  For example, as shown in step 352 of FIG. 7A, the fraud prevention sub-module 350 can compare payment card information with a list that identifies stolen payment cards. Further, as shown in step 354, the fraud prevention sub-module 350 compares the location associated with the financial institution that issued the payment card with the location corresponding to the IP address associated with the customer's computing device. Can do. The IP address associated with the customer's computing device is incorporated by the trading partner module 200 (eg, in the trading partner module 200 when the trading system 101, 102, 103 first receives trading information. By using IP address detection software). In addition, the fraud prevention sub-module 350 compares the location associated with the customer computer device's IP address with the customer billing address so that the customer computer device location is within a specified radius of the billing address. Confirm that there is something (eg 50 miles). Similarly, fraud prevention sub-module 350 compares the location associated with the financial institution that issued the payment card with the location associated with the email address provided by the customer, as shown in step 356, or As shown in step 357, the location of the customer computer device's IP address may be compared to the location associated with the email address provided by the customer. The locations compared above can include one or more countries, provinces, states, regions, counties, cities, or postal areas defined by one or more zip codes.

  Further, as shown in step 358, the fraud prevention sub-module 350 can compare the bank identification number (BIN) of the payment card with a list of suspicious BINs, and in step 360 this fraud prevention Sub-module 350 may identify and flag a customer initiated transaction with a webmail email address (eg, HOTMAIL or YAHOO email address). In addition, as shown in step 362, the fraud prevention sub-module 350 provides customer-edited information to customers who are prohibited from engaging in financial transactions with business partners within the jurisdiction of the government. Can be compared with the list. Transactions are rejected if the customer is identified with a list of persons, groups, and entities subject to jurisdiction issued by jurisdiction, such as the “Specially Designated Nationals list” issued by the United States. Similarly, as shown in step 368, the fraud prevention submodule 350 is prohibited from transacting with a business partner within a particular jurisdiction in the country associated with the customer computer device's IP address. If the IP address country is on the list, the transaction is rejected. Further, as shown in step 367, the fraud prevention sub-module 350 can compare the customer's information with a list of online business personnel, managers, or owners, and the customer can enter this list. If so, the transaction is flagged or rejected as potentially fraudulent.

  According to various embodiments, the fraud prevention sub-module 350 monitors the number of transactions for each customer or each card over a specified time period (eg, January, 1 year), as shown in step 364. Further configuration can be made. Further, as shown in step 366, the fraud prevention sub-module 350 monitors the type of transaction for each customer or card (eg, gambling transaction, travel transaction, adult entertainment transaction) over a specified period of time. Can be configured to. By monitoring the number and type of transactions on a per card or per customer basis, the anti-fraud sub-module 350, according to various embodiments of the present invention, (1) dramatically increases the pattern of card usage. If so, it can detect potential fraudulent use of the card, and (2) identify potential abuse or abuse if the customer engages in certain types of transactions more often or too often can do. The monitoring steps 364 and 366, according to one embodiment, establish a range of transaction frequency and / or type based on the customer's previous transaction and compare future transactions with the established range. Can be achieved. According to another embodiment, the range used by the fraud prevention sub-module 350 may be issued by a local government or supervisory authority, such as as an academic or institutional survey, or may include one or more participants. Established by.

  FIG. 15 illustrates the process of monitoring forced spending operations in accordance with various embodiments of the invention. In particular, starting at step 502, the IPSP module 300 receives a new request for a financial transaction. In response to receiving this new request, the IPSP module 300 is associated with a previously requested financial transaction between a particular account 31, 32, 33 and the customer, as shown as step 504. Then, the total amount of funds stored in the memory 24 is taken out. In step 506, the sum of the amount of funds withdrawn and the amount of funds associated with the new request is compared to a predetermined allowable limit of funds to be used for trading partners 31, 32, 33. If this total exceeds a predetermined tolerance limit, the IPSP module 300 exceeds the limit for the appropriate party (eg, customer, issuing bank, and / or business partner) as shown in step 508. Notify that In another embodiment of the present invention, the IPSP module 300 may retrieve the total amount of funds stored in memory for a specific time period (eg, 24 hours, 36 hours, 1 week, 1 month, 1 year). it can. Furthermore, in another embodiment, the IPSP module 300 compares the number of transactions performed between the customer and the customer for a specific period of time, and if the number of transactions performed exceeds a predetermined limit, Notify customers, issuing banks, and / or business partners that the limit has been exceeded.

  Similarly, FIG. 16 illustrates a method for monitoring forced gambling operations in accordance with various embodiments of the present invention. Beginning at step 602, IPSP module 300 receives a new request for a financial transaction. This new request includes the total amount of funds and the type of transaction (e.g., transfer of funds to a business partner, depositing a wager to a business partner, payment request from a business partner). Next, at step 604, the IPSP module 300 retrieves the total amount of funds stored in the memory 24 for the type of financial transaction in the new request. Next, in step 606, the total amount of funds and the amount of funds in the new request are compared to a predetermined tolerance limit associated with the type of financial transaction in the new request. If this total exceeds a predetermined tolerance limit, the IPSP module 300 has exceeded the limit for the appropriate party (eg, customer, issuing bank, and / or business partner) as shown in step 608. Notify that In one embodiment, if this sum exceeds a predetermined tolerance limit, the new request is rejected. In addition, the total amount of funds retrieved from memory is limited to funds stored within a particular time period, and the predetermined tolerance limits are varied based on the time period queried.

  In addition to monitoring the types of transactions described above, according to various embodiments of the present invention, the fraud prevention sub-module 350 is further configured to monitor transactions for refund requests and identify suspicious transactions. Is done. A significant number of refunds for a specific payment card by identifying transactions where the refund request information does not match the information of the original transaction, or within a specific period (eg, within a week, January, or months) In response to identifying the suspected refund request transaction by confirming that there is a request, the number of this payment card is added to the list of prohibited payment cards and future purchase transactions using this payment card It can be avoided.

  In addition to the filters described above, according to various embodiments of the present invention, the fraud prevention sub-module 350 (1) ensures that each customer uses only one payment card, and (2) It is further configured to limit payments with a specific number of transactions for each customer for a specific number of times per specific period (eg, 1 payment per day or 3 payments per 36 hours). Further, according to one embodiment, per card or customer for a specific service (eg, internet gaming or adult entertainment) for a specific time period (eg, per day, per week, per month) An upper limit can be set on the amount of money spent per hit. In one embodiment, this upper limit can be set according to customer requirements. In another embodiment, IPSP system 104 may incorporate a default limit (eg, a 20% credit limit associated with a payment card) for the amount that can be used for a particular activity. This limit cannot be increased without the explicit demand of the customer. According to one embodiment, the IPSP system 104 or the customer's system 101, 102, 103 has been specifically trained on the risk of spending more than money in response to a request to increase spending limits. Present the material to the customer, such as by telephone from an employee or email to the customer, and when a potential misuse is detected, the material or information source (eg, Gamblers Anonymous phone number, website address , Or other materials).

  In accordance with various embodiments of the present invention, the IPSP system 104 further comprises a fraud and fraud database (not shown) that stores the results from the fraud prevention submodule 350. In one embodiment, the IPSP module 300 accesses the database when processing a transaction (step 302) or when executing an anti-fraud sub-module (step 306) to identify previous payments for a particular payment card or customer. Determine if the transaction should be rejected based on fraud checks.

  As shown in FIG. 7B, the fraud prevention sub-module 350 evaluates the received transaction information using one or more of the aforementioned fraud detection filters, according to one embodiment of the present invention. Beginning at step 370, the fraud prevention submodule 350 receives transaction data from the IPSP module 300. Next, in step 372, the fraud prevention submodule 350 determines one or more fraud detection filters for use in evaluating transaction data. For example, according to one embodiment, the fraud prevention sub-module 350 uses a fraud detection filter that has been pre-selected by the business partner being used. According to another embodiment, the type of fraud detection filter used may be the transaction type (eg, authorization request, deposit cancellation request, payment request, or payment request) or transaction stage (eg, transaction information is issued by the issuing bank). Depending on whether it has not yet been sent to or whether it has already been authorized by the issuing bank. In yet another embodiment, the type of fraud detection filter used depends on the country of the IP address associated with the customer. And in another embodiment, the selection of which fraud detection filter to apply is determined by the IPSP and / or local supervisory authority. Finally, in step 374, the fraud prevention subsystem 350 executes the corresponding fraud detection filter to evaluate the transaction data.

  In addition to executing the fraud prevention subsystem 350, the IPSP module 300 is further configured to identify financial transactions that are fraudulent or subject to legal restrictions in accordance with various embodiments of the invention. Is done. For example, FIG. 18 illustrates an exemplary process for identifying fraudulent or regulated financial transactions. Beginning at step 802, the IPSP module 300 receives a request to transfer funds from a customer payment card to a business partner 31, 32, 33. The request to transfer funds includes the customer's billing address and the location of the IP address associated with the computing device that the customer uses to create the request. Next, in step 804, the IPSP module 300 regulates the transfer of funds to the customers 31, 32, 33 based on the customer billing destination, the IP address location, and the locations of the customers 31, 32, 33. Compare with a list of locations. If any of these positions matches a position on the list of positions, the IPSP module 300 allows one or more supervisors to transfer funds at any of these positions, as shown in step 806. Determine whether to regulate. If the IPSP module 300 determines that one or more supervisors will regulate the movement of funds, the IPSP module 300 may select the appropriate party (eg, customer, business partner, and And / or the issuing bank) one or more types of regulations that govern the movement of funds. The types of regulations governing financial transactions include prohibition of movement (eg, gambling transactions in states or jurisdictions where gambling is illegal) or restrictions on movement (eg, gambling in states or jurisdictions that limit the amount of stakes) Transaction).

ASP Module FIG. 8 illustrates a block diagram of an ASP module 400 according to various embodiments of the invention. The ASP module 400 is configured to operate on the ASP system 105 according to one embodiment, but the IPSP contracts with the ASP to provide account management services according to another embodiment. If not, it can be configured to operate on the IPSP system 104.

  Beginning at step 402, according to one embodiment, the ASP module 400 obtains transaction information from the IPSP system 104 and the successor bank 106. The transaction information obtained from the IPSP system 104 includes the following data fields for each transaction: (1) the customer or the trading entity of the customer (eg, a specific website) Customer identification ("MID") number given by the successor bank to identify, (2) date and time of transaction, (3) customer name, (4) payment card number or part of payment card number ( (For example, the last 4 digits), (5) the cardholder's email address, (6) the validity period of the transaction, (7) the type of payment card used (eg Visa, MasterCard, or American Express), (8) payment amount, (9) order reference number assigned to the transaction by the business partner, (10) a permission code, which is a unique code created by the issuing bank, indicating whether the transaction is permitted, (11) Transaction status (eg, “100” indicates completed transaction), (12) “processing time” when IPSP sends a processing request to the successor bank, (13) street number of cardholder, (14 ) Cardholder city name, (15) Cardholder country name, (16) Cardholder zip code, (17) Parent transaction reference, ie, first refunded in case of refund request (18) order information, which can be used to include more information about the transaction if the customer wants, (19) “site reference”, which is a reference to an IPSP customer (20) The type of transaction, including allowed transactions, refund transactions, and canceled transactions (for example, canceled transactions or money transferred to the counterparty by the issuing bank). (21) a transaction identification that uniquely identifies the transaction within the ASP system 105, including a transaction whose amount is changed at the request of the customer after the processing request is sent from the IPSP to the successor bank Reference number (URN). According to one embodiment of the invention, this information is also included in the processing request sent from the IPSP to the successor bank. This has been described previously in connection with step 310 of FIG. 6 and will be described later in connection with steps 1102 and 1104 of FIG. 10A. The transaction information obtained from the successor bank system 106 may include, for example, the total amount of funds requested by the issuing bank, collected in one or more batches in the form of each business partner.

  According to various embodiments, to obtain transaction information, the ASP module 400 accesses a secure web page (eg, maintained by each system 104, 106) where transaction information is written, and Information is downloaded to the ASP system 105 and transaction information is received via another type of electronic transmission means (eg, via email or fax) or a combination of both.

  In various embodiments, 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 shown in step 406. As compared to the information obtained from the successor bank's system 106. In the embodiment shown in FIG. 8, step 406 is shown to occur after step 404, but in other embodiments, these steps can occur simultaneously or vice versa.

  According to various embodiments of the present invention, in the comparing step 406, the ASP module 400 determines that the transaction information provided by the IPSP system 104 does not match the transaction information provided by the successor bank system 106. You may want to confirm. In one embodiment, some unmatched transactions are flagged and reported to the trading partner, IPSP, and / or successor bank in the exclusion report generated by the ASP module 400. This is described in more detail below in connection with step 410. Another embodiment in which the successor bank system 106 transfers funds directly to an account associated with each customer and maintained by the IPSP 36 and / or ASP 35 (this is described below in connection with FIG. 14). ), The ASP module 400 is further configured to compare the transaction information provided by the IPSP system 104 and the successor bank system 106 with the amount transferred to each account.

  After accepting the transaction information provided by the IPSP system 104 and the successor bank system 106, the ASP module 400 then assigns the payment amount received during the settlement process to the various participants. This is shown as step 408 in FIG. This payment amount includes, for example, the payment amount to the business partners 31, 32, 33, the fee paid to the IPSP 34, the successor bank 36, and the ASP 35, and the rotational storage escrow account 41 for each business partner 31, 32, 33. Includes the percentage of funds deposited. For example, according to various embodiments, each different participant may have a business partner 31, 32, 33 as a payment for services in business partners 31, 32, 33 and contracts 43, 45, 47, 49 with each other. Can request a certain percentage of the funds received. For example, the successor bank 36 charges 3% of the funds received by the business partners 31, 32, 33 from the issuing banks 37, 38, 39, and the card mechanism uses 1% of the funds transferred using its own card. Billing, IPSP 34 can charge 5% for payments related to services, and ASP 35 can charge IPSP 34 3% of the money received by IPSP 34 for accounting services. In another embodiment, ASP 35 provides for various services such as card verification, payment of fees to various participants, and fees billable to trading partners 31, 32, 33 for receipt cancellations received. The provisional needs received by the IPSP 34 can also be calculated.

  Further, according to various embodiments, the financial transaction system 100 can establish a protocol that defines the percentage of funds used to fund the revolving stored escrow account 41. For example, the system protocol requires that the ASP module 400 allocate 7.5% of the funds received by each business partner 31, 32, 33 to the revolving escrow account 41 for each business partner 31, 32, 33. In another example, according to one embodiment, the percentage defined for the count savings account automatically increases or depends on the number of refund requests received by a particular account 31, 32, 33. Decrease. Further, the ASP module 400, according to one embodiment, monitors and verifies funds remaining in the account for a predetermined period of time (eg, 6 months, 1 year, or 3 years) and allocates these funds. At the end of this period, reallocation is made to the business partners 31, 32, 33. Furthermore, the escrow account 41 is shown as part of the ASP system 35 in the embodiment of FIG. However, in another embodiment, this escrow account 41 exists, i.e. maintained by a bank or another financial institution.

  Next, at step 410, the ASP module 400 is configured to create a match report or “notice” for each business partner, according to various embodiments. In one embodiment, this notice is sent to each account at a matching table 406 (if necessary), a list of transactions processed for the account during a specific time period (eg, 1 day or 1 week). The generated exemption report, a list of payments assigned to each of the various participants in step 408, a list of escrow account actions within a specified period, and payments transferred to accounts 31, 32, 33. Provided date. In another embodiment, the various parts of the notification are included in separate reports (eg, an exclusion report, a payment allocation report, and a transaction summary report). And in yet another embodiment, the ASP module 400 creates one or more listing reports for the IPSP 34 and each of the business partners 31, 32, 33 based on the specific format each specifies. Composed.

  In the embodiment shown in FIG. 8, the ASP module 400 (1) sends a notice to each IP address 34 to the IPSP 34 for approval (this is shown in step 412). ), And (2) when approval is received from the IPSP 34 for the notification as shown in step 414, the notification is sent to the business partners 31, 32, 33 as shown in step 416. Further configured as: In another embodiment where IPSP 34 is not contracted with ASP 35 to provide account management services (not shown), steps 412 and 414 are not performed.

  Further, the ASP module 400 is configured to prepare payments and send them to various participants and escrow accounts according to various embodiments of the present invention, as shown in step 418. Step 418 is associated with each of the various participants who are obliged to pay money from an account associated with the ASP system 105, for example, physically sending payments to each of the participants (eg, check or cash). Including preparing a request for electronic funds transfer (EFT) in the account, or performing a combination of both. Further, although the payment step 418 is shown to occur after step 416 in the embodiment shown in FIG. 8, the ASP module 400 according to another embodiment may perform the payment step 418 simultaneously with or before step 416. It can be configured to execute.

  In another embodiment of the present invention, the ASP module 400 may be responsible for the area involved in the associated electronic commerce (eg, Internet gambling or small purchases) before sending payment to each of the business partners 31, 32, 33 It can be further configured to reduce district taxes. For example, in one embodiment, the ASP module 400 applies the applicable tax or authorization fee based on the location of the residence or each customer and / or trading location of the customer to directly relate the funds to the relevant tax or authorization. Can be configured to move to authorities.

  In particular, FIG. 17 illustrates an exemplary process for accounting for taxes that are payable in financial transactions. Beginning at step 702, the applicable tax types and corresponding tax rates for each of the one or more tax jurisdictions are stored in memory 24. Next, in step 704, information related to the financial transaction performed between the customer and the business partners 31, 32, 33 is received. In response to receiving information associated with the financial transaction, one or more associated tax jurisdictions associated with the financial transaction are identified, as shown in step 706. Next, in step 708, the memory is interrogated to determine one or more tax types associated with the identified tax jurisdiction. If more than one type of tax is associated with a specified tax jurisdiction, the corresponding tax rate for the tax type is applied to the financial transaction to determine the tax that is payable on the transaction. The This is shown in step 710. Further, once the tax to be paid for the transaction is determined, the tax amount to be paid is transferred to the relevant tax authorities, as shown in step 712. In various embodiments, taxes are levied based on the transaction originator (eg, trading partner), the customer, and / or the location of the computing device from which the customer issues an order.

  In various embodiments, the amount of tax deducted and the amount paid to the tax authority is stored in the system for a period of time using transaction information. This is a complete audit clue in some embodiments. For example, in one embodiment, the amount to be paid is held in a designated bank account and is paid to the tax authorities periodically (eg, monthly, weekly, daily, or in real time). In one embodiment, the amount to be paid is paid to the tax authority via an electronic funds transfer (EFT) function.

  According to various embodiments, this tax accounting function reduces the burden on business partners, customers, and tax authorities, and provides a reliable accounting system for taxable transactions. Further, in one embodiment, the ASP module 400 creates an accounting report for a tax authority that summarizes the taxes and / or tax deposits that it contains.

  Further, in various embodiments, transaction records can be audited electronically or manually via the ASP module 400. In particular, a unique reference number (“URN”) associated with each transaction is tracked as the transaction is processed through the system. For example, in one embodiment, multiple transactions are grouped into a batch file and sent to a successor bank for settlement. The ASP module 400 stores the URN associated with each transaction in the batch file along with information identifying the batch file so that each individual transaction can be independently audited.

C. Exemplary Processing Flow Authorization Request Processing Flow FIG. 9A illustrates a flow 1000 for processing authorization requests according to various embodiments of the invention. In one embodiment, authorization request processing occurs online while the customer is waiting, which typically takes 2 to 12 seconds to process. If this authorization request is approved by the issuing bank, the business partner accepts the customer's payment and the issuing bank blocks the amount requested beyond the credit limit or balance associated with the payment card.

  According to various embodiments of the present invention, the authorization request process 1000 may be performed by a customer 31, 32, 33 receiving a customer request to transfer money from a customer payment card to a customer account. Begin at step 1002. This request includes, for example, the amount to be transferred, customer information and payment card information (assuming the business partner does not have customer information and payment card information recorded in previous transactions). In one embodiment, customer and payment card information includes the customer's name and address, the customer's email address, and the payment card number, expiration date, and other identifying information associated with the payment card. In one embodiment, this request is received by the trading partner systems 101, 102, 103 and stored at those systems.

  Next, at step 1006, based on various embodiments of the present invention, business partners 31, 32, 33 verify the appearance of the information received in the customer's request. In one embodiment, as described above in connection with the customer module 200 shown in FIG. 5 and step 204, this customer module 200 may check whether the payment card number is correctly formatted and all Verify that the required fields are filled in.

  After verifying the information format at step 1006, the business partners 31, 32, 33 forward the transaction information to the IPSP 34 for further processing. This is shown in step 1010. The IPSP 34 receives the transaction information and stores it in the IPSP system 104, and as shown in step 1012, the succeeding bank 36 and the issuing banks 37, 38, 39 receive the information necessary for processing the authorization request. 36. For example, this information is transferred by the IPSP module 300 to the successor bank system 106 according to various embodiments of the invention and includes the payment card number, payment amount, and customer billing address. .

  Next, at step 1014, the succeeding bank system 106 receives the authorization request and stores it in the succeeding bank system 106. Next, in step 1016, the successor bank system 106 identifies the appropriate card issuer and issuer bank, and issues an authorization request to the appropriate card issuer network (eg, Visa, MasterCard, or American Express network, for example). ) To the issuing bank. Upon receipt of the authorization request, the issuing bank's system 107, 108, 109 will have sufficient payment card available and valid as shown in step 1018 and sufficient as shown in step 1020. Verify that funds are available for this payment card. Upon approval of the authorization request, the issuing bank system 107, 108, 109 sends an approval message over the card issuer network to the succeeding bank system 106, as shown in step 1022, and the succeeding bank's system 106. The system 106 receives the approval message and forwards the approval message to the IPSP system 104 at step 1024. Next, at step 1026, the IPSP system 104 receives and stores the approval message and forwards the approval message to the trading partner system 101, 102, 103 that created the authorization request.

  According to various embodiments, the basic fraud check and identity / age verification steps described above in connection with FIG. 5 (steps 204 and 206) transfer authorization request information from the trading partner to the IPSP. At the same time 1010, before or after that, executed by the business partner module 200. Further, according to various embodiments of the present invention, the step of executing the fraud prevention subsystem 350 is shown in step 306 of FIG. 6 and transfers the authorization request information from the IPSP to the successor bank 1012. At the same time, it is executed by the IPSP module 300 before or after that.

  In another embodiment of the invention shown in FIG. 13, customer information is encrypted (eg, 2048 bits) when sent to the IPSP system 104a through the partner systems 101a, 102a, 103a and the network 115a. Variable encryption). Further, the IPSP module 300a uses one or more fraud detection filters of the fraud prevention submodule 350a, and if these fraud detection filters detect a potentially suspicious activity, the IPSP module 300a Before sending the permission request to the successor bank system 106a, the result of the fraud check is sent to the business partner. After the merchant grants approval for the transaction, the IPSP module 300a forwards the authorization request to the successor bank, which in turn sends the request to the issuing bank. After the successor bank receives the authorization message from the issuing bank, the successor bank stores the transaction information in a memory area (eg, a database) of the successor bank system 106a and sends the authorization message to the IPSP system 104a. The IPSP module 300a forwards the authorization message to the customer and executes one or more fraud detection filters on the transaction information before creating a settlement request for this transaction.

Payment Processing Flow FIGS. 10A and 10B illustrate an exemplary flow 1100 for processing a payment request according to various embodiments of the invention. A settlement request according to various embodiments is a request made by the successor bank (or IPSP on behalf of the successor bank) to transfer money from the issuing bank to the successor bank to pay the business partner. According to various embodiments of the present invention, the payment request processing 1100 is performed in step 1102 by the IPSP system 104 creating a payment request for each of the business partners 31, 32, 33, and inheriting this payment request in a batch file. Start by sending to bank 36. In various embodiments, each payment request includes data regarding transactions processed by IPSP 34 for a particular period of time (eg, 24 hours, 48 hours, or 1 week). Settlement requests include authorized and unauthorized transactions or transactions that have just been authorized, according to various embodiments of the present invention. Next, according to various embodiments of the present invention, at step 1104, the IPSP system 104 stores the payment request on the IPSP system 104. These payment requests are transferred to the ASP system 105 by downloading the payment request from a secure portion of the IPSP system 104, or the IPSP 34 sends a physical or electronic copy of the payment request to the ASP 35 (eg, , Email, fax, CD, DVD, or floppy disk). The contents of the settlement request according to various embodiments of the present invention are described above in connection with FIG.

  As shown in step 1106, the successor bank 36 receives the batch file and sends a settlement request to the appropriate issuing bank 37, 38, 39. Further, as shown in step 1108, the succeeding bank 36 aggregates the amount of funds included in each settlement request to each issuing bank 37, 38, 39 (for example, aggregates the amount of funds). ), Create and save payment report for ASP35. One embodiment of a payment report generated by the successor bank 36 for the ASP 35 is described above in connection with FIG.

  Next, in step 1110, the issuing banks 37, 38, 39 transfer the requested funds to the successor bank 36. Next, in step 1112, the succeeding bank 36 transfers the received funds to the IPSP 34. Before the IPSP 34 (or ASP 35) delivers the funds to the appropriate participants and the escrow account, the ASP system 105 obtains the settlement request created by the IPSP system 104 and the payment report created by the successor bank 36, step 1114. Match the information obtained in. The results of the matching operation performed at step 1114 are summarized in a matching report (or “notification”) by ASP 35 according to various embodiments of the invention. Finally, in step 1116, the ASP 35 collects the payment amount for each participant and the amount to be transferred to the escrow account, and transfers the payment amount to the participant and the escrow account.

  According to one embodiment, ASP module 400 is configured to perform steps 1114 and 1116. This has been explained previously in connection with FIG. For example, the ASP module 400 resulted from reconciling the data provided by the IPSP and the successor bank in a reconciliation report sent periodically (eg, daily or weekly) to each business partner 31, 32, 33. Aggregate results. This match report aggregates the amount of money that a business partner 31, 32, 33 can expect to accept into a business partner's bank account by a specific date. In addition, the match report includes the total amount that the customer deposits into each account and also shows the following difficulties and advantages: (1) (covers payments for all participants in the payment chain (2) Less fees and fees, and (2) Security against withdrawals and refunds, corresponding to the percentage of the total amount held in the revolving escrow account for a certain period (eg 6 months or 1 year). There are few “trust deducts”, (3) In addition, there is “trust money” held for a certain period or one day before the date of the notice, (4) before Less reversals of deposits communicated by the successor bank on the date of the notice relating to the transaction. Prior to transferring funds to the relevant participant and revolving escrow account, IPSP 34 examines a match report that includes a date indicating that payment has been made. Upon receipt of the IPSP 34 approval for the match report, the ASP 35 transfers the match report to the various business partners 31, 32, 33 and transfers the payment to the appropriate participants and escrow account. In one embodiment, the payment transfer is made after the match report has been created and approved. In another embodiment, the payment is transferred before the matching report is approved.

  According to another embodiment shown in FIG. 14, funds are paid directly by the successor bank to each corporate account associated with each customer (eg, SG1, SG2, SG3, etc.). Further, the ASP module 400a is further configured to match the amount accepted for each account with the settlement request and payment report obtained from the IPSP and the successor bank, respectively. In one embodiment, the amount not paid from the account to the various participants or escrow accounts is paid to the business partner.

Receipt Cancel Processing Flow The request to cancel the deposit is a request initiated by the issuing bank on behalf of the customer in order to refund the special expense to the customer's payment card account. For example, the issuing bank initiates a deposit cancellation request in response to a customer claiming that the cost on the customer's payment card that the customer claims was not authorized by the customer. FIG. 11 illustrates an exemplary flow 1200 for processing a deposit cancellation request according to various embodiments of the present invention.

  Beginning at step 1202, the issuing banks 37, 38, 39 receive a request for withdrawal cancellation from a customer. Next, in step 1204, the issuing banks 37, 38, 39 send a deposit cancellation request to the successor bank 36. The successor bank 36 receives the deposit cancellation request and sends it to the IPSP 34 in step 1206. Next, in step 1208, IPSP 34 compares the withdrawal request with the data from the first transaction. If the data in the deposit cancellation request appears to match the data from the first transaction, IPSP 34 sends this request to ASP 35 in step 1210. This comparing and transmitting steps 1208 and 1210 are performed by the IPSP module 300 according to various embodiments of the present invention, as described above. Next, in step 1212, in accordance with various embodiments of the present invention, ASP 35 then transfers the amount of the deposit reversal from the customer's escrow account to successor bank 36, which in turn receives the deposit. The payment cancellation amount is transferred to the issuing bank 37, 38, 39 that initiates the cancellation request. In another embodiment, the ASP 35 pays the issuing bank 37, 38, 39 by subtracting the deposit cancellation amount from the total amount to be paid to the business partners 31, 32, 33 in the payment request. Next, at step 1214, the ASP 35 saves the deposit cancellation request. In various embodiments of the present invention, ASP module 400 is configured to perform steps 1212 and 1214.

  In step 1208, if the deposit cancellation request data does not match the data from the initial transaction, the deposit cancellation request is flagged according to various embodiments of the present invention. In addition, if the number of receipt cancellation requests flagged in relation to a particular payment card exceeds a certain number within a particular period (eg, two withdrawal requests within a week or month), IPSP will Include a specific payment card number on a list of payment cards (eg, fraud and abuse databases maintained by IPSP 34) that future business partners should not approve payments.

  In addition to the above, according to various embodiments, the ASP 35 can convert a withdrawal request processed by the successor bank 36 and the IPSP 34 within a specific period (eg, daily or weekly) into transaction data from the first transaction. Match. In order to match these requirements, ASP 35 obtains a deposit cancellation transaction report generated by successor bank 36 and a deposit cancellation transaction report generated by IPSP 34, as shown in step 1216. Compare the report with the data from the first transaction. In one embodiment, the comparing step 1216 is performed by linking the data in the withdrawal report to the data from the first transaction stored in the ASP system 105 memory. According to one embodiment, the deposit reversal data report includes at least a portion of the information that follows, which includes (1) a reference to the first information that is charged back. , (2) MID number, (3) Date when request for withdrawal of payment was made, (4) Description of transaction as “payment withdrawal”, (5) All card numbers, (6) Verification provided by successor bank Number, (7) a code number issued by the card issuer that indicates why the deposit cancellation was initiated by the cardholder, (8) a description of why the deposit cancellation was initiated, (9) currency type for the deposit cancellation amount (10) Deposit cancellation amount, (11) Card number or part of it (eg, the first 4 digits of the card number) given by the successor bank, (12) The first transaction must be “published” (13) Date of first transaction, (14) “Type” of first transaction, (15) Currency of first transaction, (16) Amount of first transaction, (17) Transaction (18) the amount settled, (19) the first “default” currency provided by the successor bank, (20) the first “default currency” amount provided by the successor bank, ( 21) “original slip”, which is a reference material for a “batch” of some of the transactions when the succeeding bank has released its data on transactions on a specific date to IPSP, (22) “ "Slip", (23) Authorization code for the first transaction, (24) Successor bank's "batch number", and (25) The name of the account as it appears on the customer's payment card statement. DBA name " It is. As previously described in connection with FIG. 8, the ASP module 400 is configured to perform this matching step 1216 in accordance with various embodiments of the invention.

  In accordance with various embodiments of the present invention, the report is mailed to and downloaded by the ASP system 105 and the successor bank system 106, or the report can be e-mail, fax, CD, for example. , DVD, or floppy (registered trademark) disk, physically or electronically.

Payment Processing Flow Some e-commerce departments (eg, gambling) require money to be paid back to the customer. Paying money to customers raises concerns about the dangers of misusing money laundering, especially for Internet gambling. In accordance with various embodiments of the present invention, the system 100 allows the customer and business partner to make an exclusive payment to the account on the payment card used by the customer to make the initial payment to the business partner. By addressing some of the risks associated with electronic commerce by creating a completely transparent “closed loop” between them. Thus, according to one embodiment, money flows from the same account and back to the same account, so all gold flows are traceable, which makes e-commerce attractive for money laundering plans Not.

  For example, FIG. 12 illustrates an exemplary flow 1300 for processing payments and transferring payments to a customer when the customer submits a payment request. Beginning at step 1302, the business partner receives a request from the customer for payment and forwards the request to the IPSP. Next, in step 1304, the IPSP verifies that the customer is not on the government or local permit list (eg, a “specially designated country list” issued by the United States). In addition, according to one embodiment, the IPSP prohibits the customer's nationality (eg, based on the customer's billing address or the IP address of the customer's computer device) that the customer may be doing business. Verify that it is not on the list of registered countries. According to various embodiments, if a customer (or customer country) is on the list, the request is rejected because the system 100 cannot allow the payment request. If the customer is not on the allowed list (or is not associated with a banned country), IPSP 34 sends a payment request to the bank of the customer. This is shown as step 1306. Upon receiving the request and receiving the payment funds in the customer's account, the customer's bank transfers the funds to IPSP 34. This is shown as step 1308. After IPSP 34 receives the funds and saves their records in IPSP system 104, IPSP 34 transfers the funds to successor bank 36, as shown in step 1310. Next, at step 1312, when the successor bank 36 receives the funds, the issuing bank 37, 38, associated with the customer's payment card used to purchase (eg, place a wager) on the customer's web. 39, send this money. According to various embodiments, at step 1314, the issuing bank 37, 38, 39 then transfers the amount received from the business partner 31, 32, 33 to the account associated with the payment card or the cardholder. Send checks to customers listed as.

Electronic Wallet In yet another embodiment of the present invention (not shown), financial transaction system 100 is configured to allow customers to purchase electronic tokens from IPSP 34. In this case, the electronic token can be used for the business partners 31, 32 and 33 who participate in the agreed amount, and a prepaid “electronic wallet” account is created. According to various embodiments, the functionality of the financial transaction system 100 can be extended to an electronic wallet system. For example, instead of trading partners 31, 32, 33 receiving a request from a customer and transferring funds from the account associated with the customer's payment card to the trading partner's account, the IPSP 34 receives the request and transfers the funds to the customer's electronic wallet. To the IPSP account. According to one embodiment, IPSP 34 executes the steps of supplier module 200 and IPSP module 300 to create and process authorization requests and settlement requests to the issuing bank. When payment is made, the IPSP 34 transfers the amount of the electronic token representing the amount of funds transferred to the account of the customer's electronic wallet. The customer can use the token for the participating business partners 31, 32, 33 to purchase. Periodically (eg, daily or weekly), the IPSP 34 transfers funds representing the amount of tokens used on each supplier's website to each of the suppliers 31, 32, 33. In one embodiment, the ASP 35 manages the electronic wallet account and assigns payments from the IPSP 34 to the related business partners 31, 32, 33.

  Many variations and other embodiments of the invention will occur to those skilled in the art to which the invention pertains having the doctrine advantages shown in the foregoing description and the associated drawings. Thus, it should be understood that the invention is not limited to the specific embodiments disclosed, and that variations and other embodiments are intended to be included within the scope of the appended claims. Although special terms are used in the present application, these terms are general and are used for illustration only and are not intended to limit the scope of the present invention.

Claims (2)

A system for monitoring suspicious fraud with a processor and memory,
The processor is
Storing in the memory information associated with each of the one or more requests from the customer to transfer funds and the date the request was received;
Receiving a new request from the customer for one or more future transactions to transfer funds;
In response to receiving the new request, determining the frequency of transactions stored in the memory in a specific period,
Establishing a transaction frequency range and a transaction type range based on the customer's previous business with the customer;
Comparing the transaction frequency and the transaction type based on the new request for one or more future transactions with the established transaction frequency range and the established transaction type range;
One or more customers, a payment source associated with the customer, if the transaction is outside the scope of the established transaction type, or if the transaction frequency is less or greater than the established transaction frequency range; Or notifying the business partner that suspicious fraud has been detected. The processor of claim 1, wherein the processor is configured to flag the request as a potential fraud in response to a frequency of the transaction that is less or greater than a range of the frequency of the established transaction . system.

Images