EP1559044A4 - Procede et systeme de gestion de transactions financieres - Google Patents

Procede et systeme de gestion de transactions financieres

Info

Publication number
EP1559044A4
EP1559044A4 EP03774754A EP03774754A EP1559044A4 EP 1559044 A4 EP1559044 A4 EP 1559044A4 EP 03774754 A EP03774754 A EP 03774754A EP 03774754 A EP03774754 A EP 03774754A EP 1559044 A4 EP1559044 A4 EP 1559044A4
Authority
EP
European Patent Office
Prior art keywords
information
cash
party
record
country
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
EP03774754A
Other languages
German (de)
English (en)
Other versions
EP1559044A2 (fr
Inventor
Wendy Yusin
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
First Data Corp
Original Assignee
First Data Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by First Data Corp filed Critical First Data Corp
Publication of EP1559044A2 publication Critical patent/EP1559044A2/fr
Publication of EP1559044A4 publication Critical patent/EP1559044A4/fr
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G06Q20/023—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP] the neutral party being a clearing house
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/02—Banking, e.g. interest calculation or account maintenance

Definitions

  • FIG. 1 is a schematic diagram of a prior art credit card transaction system 10 in the United States.
  • a credit card transaction When a credit card transaction is processed, data required to effectuate (or settle) the transaction is entered, a request for authorization to complete the transaction (based on the transaction data) is generated, an authorization is either granted or denied, and if authorization is granted, necessary funds to effectuate the transaction are transferred.
  • Such a transaction typically involves multiple parties including a Credit Card Holder 12, an Acquiring Bank 14, a Merchant 16, a Bank Card Association 18, and an Issuing Bank 20. While only one of each party is shown for ease of illustration, it is understood that there is a plurality of each party in a credit card transaction system.
  • the Credit Card Holder 12 is an entity, such as a person or business, that purchases goods or services from the Merchant 16 using a credit card issued by the Issuing Bank 20.
  • the Merchant 16 is an entity, such as a business or person, that sell goods or services and is able to accept and charge credit cards to complete the sale.
  • the Merchant 16 may be a point of sale Merchant.
  • the Bank Card Association 18 is a credit card payment service association (such as Visa and MasterCard) that is made up of member financial institutions.
  • the Bank Card Association 18 sets and enforces rules governing their credit cards and conducts clearing and settlement processing.
  • the Bank Card Association 18 neither issues cards nor signs merchants. Instead, it licenses financial institutions, such as the Issuing Bank 20, to issue cards, and licenses the Acquiring Bank 14 to acquire merchants' sales drafts under the Association's brand name.
  • the Bank Card Association 18 then manages the transfer of transaction data and funds between the Issuing Bank 20 and the Acquiring Bank 14.
  • the Bank Card Association 18 maintains national and international networks tlirough which data and funds are moved between the Credit Card Holder , the Merchant 16, the Acquiring Banks 14 and the Issuing Bank 20.
  • the Acquiring Bank 14 is an entity that owns the legal relationship with the Merchant 16.
  • the Bank 14 buys (acquires) the rights to the sales slips of the Merchant 16 and credits the value of the sales slip to the Merchant's account at the Bank.
  • the Acquiring Bank 14 effectuates payment to the Merchant 14 upon authorization of a credit card transaction and charges the Merchant 14 a fee for handling each transaction.
  • the Issuing Bank 20 issues credit cards to approved Card Holders, such as Card Holder 12, receives and pays for transactions from the Bank Card Association 18 and sends bills to and collects payment from the Credit Card Holder 12.
  • a Platform 22 serves as the liaison between the Merchant 16 and the Bank Card Association 18.
  • the Platform 22 seeks authorization for the credit card transaction and conveys the authorization or rejection to the Merchant 16.
  • the Platform also computes the interchange fees associated with each credit card transaction processed by the Merchants 16 in accordance with predetermined business rules established by the Bank Card Associations 18.
  • the Merchant 16 requests authorization from the Platform 22 (C).
  • the Platform requests authorization from a Bank Card Association 18 (D) and ultimately the Issuing Bank 20 (E).
  • the request for authorization is transmitted from the Merchant 16 to the Issuing Bank 20 through the Platform 22 and Bank Card Association 18.
  • the resulting authorization (or rejection) (F) is then issued by the Issuing Bank 20a and transmitted back to the Merchant 16 through the Bank Card Association 18 (G) and the Platform 22 (H).
  • the Merchant 16 Upon completion of the transaction, the Merchant 16, at some subsequent point in time, is paid the transaction price by the Acquiring Bank 14 (J) that has purchased the rights to the Merchant's sales slips (J).
  • the Acquiring Bank 14 receives payment from the Issuing Bank 20 (K).
  • the Acquiring Bank 14 and the Issuing Bank 20 typically have their own clearing networks to effectuate their payments.
  • dollars and/or need money transferred to a bank account outside of the U.S. must separately arrange for the movement of cash in each country in which it transacts business, with financial institutions in each respective country.
  • financial institutions may include banks and clearing houses, for example.
  • File formats in each country must be conformed to, typically by working with the local financial institution that works with the local requirements. Institutions may use proprietary software to provide this function.
  • One example of a detail related to money transfer that varies from country to country is the threshold for a monetary value above which money must be transferred by wire transfer. High value money transfers involving monetary values above the threshold must be conducted by wire transfer. Low value money transfers involving monetary values at or below the threshold are typically conducted through an automated clearing house. For example, in Germany, money values over 25,000 Euros are considered to be high value and must be transferred by wire. The parties to the transaction may request wire transfer for monetary values below the threshold, as well.
  • countries may also have different cut off time frames within which money transfers must be completed on a particular day. If money transfer is not completed by the cut off time, the money transfer is deferred until the next day.
  • Time frames may vary from 4-5 days, for example.
  • Banks in different countries may also be open on different days. For example, banks in Israel are open on Sundays. Banks in Muslim countries may be closed on Fridays. Some banks in the United States may be open on weekends, as well.
  • a plurality of clearing houses are available. When a choice of clearing house is available, use of a particular clearing house is dictated by the financial institutions involved, many of which have their own clearing networks.
  • the clearing house and associated banks in a particular country may also have different information, format and security requirements. For example, file encryption using secure keys may be required. Router codes to convey the file to the financial institution may be required, as well. Fraud is an ever present problem in cash transfer transactions.
  • a known scheme in the credit card environment for example, is for point of service merchants to inflate sales charges to customers using credit cards, for products that have not been purchased. The merchant will typically be paid before the customer receives a statement and has an opportunity to question the charge. After the merchant receives the payment, the merchant closes the bank account into which the payment was made. Once the account is closed, it is difficult for the credit card company to retrieve a payment for an improper charge.
  • a method of managing a cash transfer by or on behalf of a first entity to an account of a second entity comprising receiving information related to the cash transfer and formatting the information into one of a plurality of formats based, at least in part, on a location of the account.
  • the account may be a bank account.
  • the location of the account may be the country where the account is located. If the account is located in the United States, the information may be formatted in an National Automatic Clearing House Association (NACHA) format, for example. If the account is located outside of the United States, the information may be formatted in a United Nations Electronic Data Exchange Administration, Commerce and Transport (UN/EDIFACT) format, for example.
  • NACHA National Automatic Clearing House Association
  • UN/EDIFACT United Nations Electronic Data Exchange Administration, Commerce and Transport
  • Country specific information including required data and formatting, may be added to the formatted information to tailor the information for clearance and settlement of funds in the particular country where the second entity's account is located.
  • the information may be provided from a platform chosen from the group consisting of a credit card processor, a bank, a business-to-business gateway for electronic fund transfer, a business-to-consumer gateway for electronic fund transfer or a consumer-to-business gateway for electronic fund transfer, for example.
  • the cash transfer may relate to a transaction between the first and second entities such as a credit card transaction, a debit card transaction, a payment by check, an electronic funds transfer and a wire payment between the first and second entities.
  • the country specific information may also include any or all of the following for example a time beyond which cash transfer cannot take place may be determined for a particular country, and that time may be added to the formatted information.
  • a value date for money transfer in that country, by which date money must be transferred into the account, may be determined and added to the formatted information.
  • a threshold for a monetary value above which a cash transfer must take place by wire transfer may be determined and used to determine whether the cash must be transferred by wire transfer or could be transferred by a low value clearing, and an indication of an acceptable mode of transfer of the cash transfer may be added to the formatted information based, at least in part, on the threshold.
  • One of a plurality of clearing networks may be selected to clear and settle the cash transfer and added to the formatted information.
  • Information about the second entity may be stored in memory for comparison to received information about the second entity in the information related to the cash transfer.
  • the stored information and the received information may be compared. Differences in information such as bank account and entity names may be indicative of fraud.
  • Processing of the cash transfer may be stopped and/or the party providing the information about the cash transfer may be notified.
  • the cash transfer may relate to a transaction between the first and second entities such as a credit card transaction, a debit card transaction, a payment by check, an electronic funds transfer and a wire payment between the first and second entities.
  • a method of managing cash transfers by or on behalf of at least one first entity to a bank account of at least one respective second entity comprising receiving information related to the cash transfer in the form of a file comprising at least one record related to a respective cash transfer, from a party.
  • the method formats the information in the at least one record into one of a plurality of formats based, at least in part, on a country where the bank account of the second entity related to the cash transfer of the record is located, to form a formatted record.
  • the method then sends a file comprising at least one formatted record to a clearing network.
  • a method of managing cash transfers by or on behalf of at least one first entity to a bank account of at least one respective second entity comprising receiving information about a second entity, from a party and storing the received information about the second entity.
  • the method receives information related to the cash transfer in the form of a file comprising at least one record related to a respective cash transfer and compares the received information about the second entity to the stored information.
  • this method may help detect changes in information such as bank account numbers and entity names, that could be fraudulent.
  • a method of managing cash transfers by or on behalf of at least one first entity to a bank account of at least one respective second entity comprising receiving information related to the cash transfer in the form of a file comprising at least one record related to a respective cash transfer, from a party.
  • the method sends the information to a clearing network to clear and settle the cash transfer.
  • the method receives information from the clearing network concerning a status of the clearance and settlement of the cash transfer and informs the party of the status.
  • the party may be a platform, as discussed above. This method enables the platform or other such party to learn of the status of the cash transfer so that its accounting information may be kept current.
  • the second entity may also be learn of the status from the platform, which assists the second entity in its accounting.
  • the method may also inform a second party contractually associated with the first entity or the second entity with respect to cash transfer, of the status.
  • a method of managing cash transfers by or on behalf of at least one first entity to a bank account of at least one respective second entity comprising receiving information related to a cash transfer in the form of a file comprising at least one record related to a respective cash transfer, processing the record, receiving a request for access to status information related to the status of the processing of the record and selectively granting access to the status information.
  • the method may further comprise sending the record to a clearing network to clear and settle the cash transfer, receiving information from the clearing network concerning a status of the clearance and settlement of the cash transfer and allowing access to information about the status of the processing of the record by the clearing network, to the at least one selected party.
  • the selected party may be contractually associated with the first party or the second party with respect to the cash transfer.
  • a system for managing a cash transfer by or on behalf of a first entity to an account of a second entity comprising means for receiving information related to the cash transfer and means for formatting the information into one of a plurality of formats based, at least in part, on a location of the account.
  • a system to manage a cash transfer by or on behalf of a first entity to an account of a second entity comprising memory to store information related to the cash transfer and a processor coupled to the memory.
  • the processor is programmed to fo ⁇ nat the information into one of a plurality of formats based, at least in part, on a location of the account.
  • the account may be a bank account and the location may be a country where the account is located.
  • a system to manage cash transfers by or on behalf of at least one first entity to a bank account of at least one respective second entity comprising an interface to receive information related to the cash transfer in the form of a file comprising at least one record related to a respective cash transfer, from a party.
  • the system also comprises memory to store the file and a processor coupled to the interface and to the memory.
  • the processor is programmed to format the information in the at least one record into one of a plurality of formats based, at least in part, on a country where the bank account of the second entity related to the cash transfer of the record is located, to form a formatted record.
  • the processor is also programmed to send a file comprising at least one formatted record to a clearing network, via the interface.
  • a system to manage cash transfers by or on behalf of at least one first entity to a bank account of at least one respective second entity comprising an interface to receive information about a > second entity, from a party, and information related to the cash transfer in the form of a file comprising at least one record related to a respective cash transfer, from the party.
  • the system further comprises memory to store the information about the second entity and the information about the cash transfer.
  • the system further comprises a processor coupled to the interface and to the memory. The processor is programmed to compare the information about the second entity to the information about the cash transfer to identify differences in the same type of information. As discussed above, this can help detect fraud.
  • a system to manage cash transfers by or on behalf of at least one first entity to a bank account of at least one respective second entity comprising an interface to receive information related to the cash transfer in the form of a file comprising at least one record related to a respective cash transfer, from a party.
  • the system further comprises memory to store the received information.
  • the system further comprises a processor coupled to the interface and to the memory. The processor is programmed to send the information to a clearing network to clear and settle the cash transfer and to inform the party of a status of the clearance and settlement of the cash transfer.
  • a system to manage cash transfers by or on behalf of at least one first entity to a bank account of at least one respective second entity comprising an interface to receive information related to the cash transfer in the form of a file comprising at least one record related to a respective cash transfer, from a party.
  • the system further comprises memory to store the received information and a processor coupled to the interface and to the memory.
  • the processor is programmed to process the record for cash transfer and allow access to information about the status of the processing of the record by the system, to at least one selected party.
  • the processor may be further programmed to send the information to a clearing network to clear and settle the cash transfer and inform the party of the status of the clearance and settlement based on information received from the clearing network.
  • the selected party may be contractually associated with the first entity or the second entity with respect to the cash transfer,
  • FIG. 1 is a schematic diagram of a prior art credit card transaction system in the United States
  • Fig. 2 is an example of a Financial Transaction Clearing System for U.S. and/or international cash transfers that may implement embodiments of the present invention
  • Fig. 3 is a block diagram of the TM 106 in accordance with an embodiment of the invention
  • Fig. 4 is a simplified representation of the System of Fig. 1, showing certain of the file transfers and file conversions discussed herein;
  • Fig. 5 is an example of a method of operation of the Financial Transaction Clearing
  • Fig. 6 is an example of a method of managing transactions in accordance with an embodiment of the invention.
  • Fig. 7 is an example of a method for generating a Worldwide Funding File in accordance with an embodiment of the present invention
  • Fig. 8 is a continuation of the method of Fig. 6
  • Fig. 9 is a continuation of the method of Fig. 5;
  • Fig. 10 is an example of another method of in accordance with another embodiment of the invention.
  • Fig. 11 is a continuation of the method of Figs. 5 and 9;
  • Fig. 12 is a continuation of the method of Fig. 10; and Fig. 13 is an example of a method of another embodiment of the invention.
  • Fig. 2 is an example of a Financial Transaction Clearing System 100 for U.S. and/or international cash transfers that may implement embodiments of the present invention.
  • the System 100 authorizes and effectuates the cash transfer from or on behalf of first entities 101a, 101b, 101c . . . 101 n, which may be consumers, businesses, and banks, for example, to second entities 102a-102n, which may be businesses, such as point of sale ("POS") merchants, individuals, banks, independent service organizations (“ISOs”), or agents, for example, in exchange for the sale of goods or the performance of services.
  • the first entities 101a-101n and the second entities may be located anywhere in the world.
  • the cash transfer may be initiated through a credit card transaction, a debit card transaction, a check, an electronic check payment, an electronic funds transfer, a wire payment, etc.
  • Institutions 105a, 105b..105n are typically contractually obligated to the first or second entities 101 a- 101 n, 102a- 102n, whereby they own and manage the legal relationships with the first and second entities lOla-lOln, 102a-102n.
  • Institutions may include Issuing Banks and Acquiring Banks (see Fig. 1). Wells Fargo Merchant Services, San Francisco, California is an example of such an Institution.
  • the Institution In electronic fund transfers, the Institution may be a second entity 102a-102n that is large enough to perform this function on its own behalf and banks. Large organizations may assume the role of the Institutions 105a-105n in electronic fund transfers.
  • TM Transaction Manager
  • U.S. transactions are those in which the bank account of the second entity 102a-102n to which the cash is to be transferred is located in the United States and the currency of payment is U.S. dollars.
  • International transactions in this embodiment are those in which the bank account of the second entity is located outside of the U.S. and/or the currency is not U.S. dollars.
  • Funds to settle the cash transfer may be provided by Payment Sources 108, which may be bank accounts of Acquiring Banks and Issuing Banks, credit card companies, debit card companies, etc.
  • the funds are provided to one of a plurality of Clearing Networks 112, 112a . . . 112n, here, Clearing Network 112, for example, which moves the funds to a bank account of the second entity 102a, based on instructions from the TM 106.
  • the internal structures of the Clearing Networks 112a-l 12n which are not shown to ease illustration, are the same as shown for the Clearing Network 112.
  • the funds to be transferred to the second entity 102a may be kept in a Bank 113, in respective Cash Accounts 114a, 114b . . .
  • the Clearing Network 112 may cause the money to be moved from an appropriate one of the Cash Accounts 114a-l 14n or from an appropriate one of the Payment Sources 108 into the bank account of the second entity 102a.
  • the account of the second entity 102a may be in one of a plurality of Network Beneficiary Banks 118a, 118b, 118c . . . 118n that is part of the Clearing Network 112, or in one of a plurality of Local Beneficiary Banks 120a, 120b, 120c . . . 120n, via an appropriate Network Bank.
  • the Network Beneficiary Banks 118a-l 18n are located in respective countries throughout the world where the System 100 can clear and settle funds.
  • One or more Local Beneficiary Banks 120a-120n are also located in countries around the world.
  • the system 10 may comprise a plurality of Platforms.
  • the second entities 102a-102n may provide information related to the cash transfer to the Platform 104 with which it has contracted to start to process details related to the transfer.
  • Transaction details may be provided from the second entities 102a-102n to the Platform 104 in a Transaction File via a File Transfer Protocol ("FTP"), for example.
  • FTP File Transfer Protocol
  • the Platform 104 and the TM 106 are preferably connected via a direct telecommunications connection. They may be connected via the Internet or an Intranet, as well.
  • One or a plurality of transactions may be described in the Transaction File.
  • the Platform 104 may be a credit card processor, a bank, a business-to-consumer, business-to-business and/or consumer-to- business gateway for electronic fund transfers, or other such party, which are known in the art.
  • Second entities 102a-102n that are POS merchants may also seek authorization for individual credit card and debit card transactions via the Platform 104, as discussed above with respect to Fig. 1.
  • the second entities 102a- 102n may provide the information directly to the Platform 104 or through an intermediary, such as a bank or ISO 130, with a relationship with a respective second entity 102c, for example, as is known in the art.
  • the Platform 104 may comprise either or both of First Data Merchant Services ("FDMS"), Coral Springs, Florida and Omnipay Ltd., Dublin, Ireland. Omnipay Ltd. may be the international processing partner of FDMS, for example.
  • FDMS First Data Merchant Services
  • Omnipay Ltd. may be the international processing partner of FDMS, for example.
  • the Platform 104 generates a Basic Funding File including relevant information provided to the Platform 104 by the second entities 102a-102n, for one or more transactions (cash transfers).
  • the Basic Funding File typically identities the parties to a transaction (the first entity 101a and the second entity 102a, for example), the cash value of the transaction, the date and time of the transaction, the currency of the transaction, identifying information of the bank and bank account of the second entity 102b where the money is to be transferred, the date of receipt by the Platform 104 of the transaction details, the currency of the transaction, the Institution 105a-105n owning or otherwise contractually related to the transaction, and other details related to the transaction, as is known in the art. Information related to each transaction is described in a respective Detail Record in the Basic Funding File.
  • the Detail Records in the Basic Funding File may be from one or a plurality of entities 102a-102n and from one or a plurality of Transaction Files.
  • the Platform 104 also preferably determines whether the transaction is a U.S. transaction or an international transaction, based on the criteria described above, for example. Such information is typically provided in each Detail Record in the Basic Funding File. U.S. transactions and international transactions may be included in the same or different Basic Funding Files.
  • the Basic Funding File is sent to the Transaction Manager ("TM") 106, which checks the Basic Funding File for errors and converts the Detail Records in the File into an appropriate format for clearance and settlement of the funds.
  • the appropriate format may be dependent upon the country where the bank account of the second entity 102a-102n for that Detail Record is located.
  • the format should be compatible with the requirements of the bank holding the bank account and the clearing institutions that are used to clear the cash transfer.
  • the selected format is dependent upon whether the file is for U.S. transactions or international transactions, as described below. It may also be dependent on the Clearing Network 112 being used, as is also described below.
  • the File may be transferred by FTP, for example, preferably along direct telecommunications connections, such as between directly connected routers 107a, 107b.
  • the router or routers 107b in the Clearing Network are under the control of the TM 106, as discussed further .
  • Detail Records for U.S. transactions are preferably converted into a U.S. standard formatted file.
  • the standard format for U.S. transactions is the National Automated Clearing House Association (“NACHA”) format, which is known in the art.
  • Detail Records for international transactions are converted into an international formatted file.
  • the standard format for international transactions is the United Nations Electronic Data Exchange Administration, Commerce and Transport format (“UN/EDIFACT”), which is also known in the art. If the Clearing Network is ABN AMRO Bank, Amsterdam Netherlands (“ABN AMJRO”), the Detail Records in the Basic Funding File for all transactions are converted into the UN/EDIFACT format for all cash transfers, including transfers of U.S. dollars to a U.S. bank account.
  • the converted Basic Funding Files, formatted for U.S. and for international fransactions are referred to herein as a "Worldwide Funding Files.”
  • the type and format of information required to settle international transactions may vary from country to country.
  • the TM 106 further incorporates country specific information into the Worldwide Funding File, which is required for the clearing institutions in a particular counfry. If ABN AMRO is the Clearing Network 112 for the transfer of U.S. dollars to a U.S. bank account, the UN/EDIFACT format is used and the
  • U.S. country specific information in the NACHA format is added. If the currency is not U.S. dollars and/or the bank account is not in the U.S., the country specific information and format for the country where the bank account is located is added to the Worldwide Funding File.
  • the Worldwide Funding File is referred to as a "Country Specific Funding File.”
  • the Country Specific Funding File preferably contains only Detail Records pertaining to cash transfers to bank accounts in a single country.
  • Detail Records for cash transfers to bank accounts in different countries may be in the same Country Specific Funding File, as well. If that is the case, Detail Records for cash transfers to the same country may be in subfiles within the Country Specific Funding File.
  • the TM 106 may be administered by the same party or parties that perform the function of the Platform 104, such as FDMS.
  • the TM 106 may also be administered by another party.
  • the Platform 104 preferably provides the Basic Funding File to the TM 106 in a format requested by the TM 106, to facilitate processing by the TM 106.
  • the TM 106 provides the Country Specific Funding File to an appropriate Clearing
  • the Clearing Network 112 may comprise a Clearing House 115, which processes the Country Specific Funding File to determine if all requirements for further processing are met, and sends the File to a Clearing Gateway 116.
  • the Clearing Gateway 116 analyzes the Country Specific Funding File to identify an appropriate one of the Network Beneficiary Banks 118a- 118n, here Bank 118a, for example, in the same counfry as the bank account of the entity 102a initiating the transaction, and directs the File to that Bank.
  • the Network Beneficiary Banks 118a- 118n are part of or are affiliated with the Clearing Network 112.
  • the Bank 113 includes In Country Accounts 119a, 119b . . . 119n, which are each located in a country where funds may need to be settled. While not required, this is preferred for tax purposes.
  • Cash for settlement is preferably transferred from the Cash
  • the money necessary to settle the transaction may be transferred from the appropriate In Country Account 119a to that account. If the entity 102a does not have an account with a
  • the TM 106 monitors the progress of the Country
  • Fig. 3 is a block diagram of the TM 106 in accordance with an embodiment of the invention.
  • the TM 106 may comprise interfaces 130a, 130b, a processor 132 and memory 134.
  • the interface 130a may couple the TM 106 to the Platform 104 via the Internet or an Intranet, for example.
  • the interface 130b preferably couples the TM 106 to the Clearing Network 112 via a direct telecommunications connection.
  • the interface 130b may comprise one or more routers 107a with a direct connection to one or more routers 107b in the Clearing Network 112 (See Fig. 2), for added security.
  • the router or routers 107b in the Clearing Network are preferably under the control of the TM 106, as well.
  • Files sent to the Clearing Network 112 may therefore be both encrypted and decrypted by the TM 106, prior to transferring the File to the Clearing Network.
  • the TM 106 may also be coupled to the Clearing Network 112 via the Internet or an Intranet, but that is not preferred.
  • the processor 132 may be one or more central processing units.
  • the memory 134 generically includes disks, caches and volatile and non- volatile memory.
  • the memory 134 may comprise random access memory (RAM) 135 for, among other functions, storage of information and files for processing.
  • the memory 134 may also comprise read only memory (ROM), including a hard drive 136 to store the software program or programs for controlling operation of the TM 106.
  • ROM read only memory
  • Other types of data storage devices may be used, as well.
  • the memory 134 may further comprise databases containing information necessary for the creation of the Worldwide Funding File, the Country Specific Funding File and other processing functions of the TM 106.
  • the TM 106 may be an AS/400 server available from IBM Corporation, Armonk, JNY, for example. Examples of databases are discussed below. Other database arrangements may be used, as well.
  • the TM 106 has the ability to compare the current information provided by the Platform 104 in the Basic Funding File to information previously provided by the Platform 104 about the second entity 102a- 102n. Changes in such information may be indicative of fraud. For example, when a second entity 102a contracts with the Platform 104, the entity typically provides identifying information, such as the entity's name, address, name of bank and bank account number where money is to be transferred to, etc., to the Platform 104. The Platform 104 may in turn provide that information to the TM 106. TM 106 may store this information in an Identifying Information Database 138, for example, associated with an identification number of that entity 102a.
  • the identifying information in the Detail Record may be compared to the identifying information in the Identifying Information Database 138, to determine if they are the same. If not, the Platform 104 may be informed of the change. One or more changes, or multiple changes over time, may cause the Detail Record to be rejected due to a suspicion of fraud. In one implementation, a minor change, such as a change in name of the second entity 102a in a Detail Record, will cause the account to be flagged. A report may be generated and sent to the Platform 104, but the Detail Record may not be rejected. Subsequent changes by that second entity 102a may, however, cause rejection of the Detail Record.
  • a Database 138a may be provided to store such changed events with respect to the respective second entity 102a, so that such changes may be monitored. Database 138a may be part of the Identifying Information Database or may be a separate database.
  • the TM 106 may also dete ⁇ nine whether a transaction to transfer cash into a specific country is considered by that country to be high value transaction that needs to be sent by wire transfer or a low value transaction that may be sent by automated clearing house, based on thresholds established by the country where the bank to receive the money is located. For example, in Germany, transactions above 25,000 Euros must be transferred by wire. In the U.S., while there are no formal requirements or regulations, transactions above 1 million dollars are generally conducted by wire.
  • the memory 134 may include a Country Specific Threshold Database 140, which contains the respective monetary value thresholds for particular countries for high and low value transactions. Wire transfer is well known in the art.
  • countries may also have different information and formatting requirements for transaction files to be processed and cash fransferred through their clearing institutions, such as the Network Beneficiary Banks 118a-118n and Local Beneficiary Banks 120a-120n.
  • Such information and formatting requirements need to be incorporated in the Worldwide Funding File to form the Country Specific Funding File.
  • the Worldwide Funding File For example, for transactions involving pounds and/or a second entity 102a in England, the Bankers Automated Clearing Service, Ltd. (“BAGS”) fonnat is required.
  • BAGS Bankers Automated Clearing Service, Ltd.
  • CAP Canadian Payments Association
  • Country Specific information may include the length of fields. For example, in one country, a bank account field may be 10 spaces and in another country, the bank account field may be 12 spaces.
  • the Worldwide Funding File in UN/EDIFACT format is modified to conform to the requirements of the country to which the cash is to be transferred.
  • Other counfry specific information may include the number of decimal places in a country's currency. For example, when denominating money in Japanese Yen, decimals are not used. When denominating money in U.S. dollars or Euros, two decimal places are used. Some currencies use three decimal places. Even though a currency may use three decimal places, to simplify processing, the TM 106 may limit the number of decimal places to two, which is sufficient for most currencies. Currencies with three decimal places would then be rounded off to two decimal places.
  • This Country Specific information may be stored in a Country Specific Database 142 in the TM 106.
  • the currency/decimal place correlation may be stored in a currency table in Database 142, for example.
  • a plurality of databases or tables may be provided, each dedicated to a different type of country specific information.
  • the TM 106 may include a Country Specific Cut Off Time Frame Database 144, which contains the respective cut off time frames for particular countries, as well. In the U.S., individual banks may have their own cut off time frames, which may also be stored in the Database 144 or another such Database.
  • countries also have regulations concerning when cash needs to be transferred into an account of a second entity 102a.
  • countries typically require the cash to be transferred within 4 or 5 business days of the transaction, for example.
  • the date by which cash transfer is required is referred to as a value date.
  • a value date indicator indicative of the number of days may be provided by the Platform 104 in the Basic Funding File.
  • the number of days may be defined in contracts between the Platform 104 and the entity 102a-102n, as well.
  • the actual payment date may be calculated by the processor 132 of the TM 106, based on the value date, the date of the transaction and counfry specific rules and practices concerning what counts as a "business day.” For example, banks may be opened in different countries on different days.
  • a plurality of Clearing Networks 112, 112a-l 12n are available.
  • the TM 106 may select one of the available Clearing Networks 112, 112a-l 12n to use for particular Detail Records based on the fees charged by the Network, the time required for the Network to settle the transaction underlying the Detail Record, the capabilities of the Network, etc.
  • the capabilities of the Clearing Network 112 include whether the Network can clear and settle funds in the particular country where the second entity 102a-102n has their bank account.
  • Such information may be stored in a Clearing Network Specific Database 146.
  • the Clearing Network 112 and the Network Beneficiary Banks 118a-l 18n for the transaction in a particular country may also have information, fonnat and security requirements. For example, file encryption using secure keys may be required. Router codes to convey the file to the financial institution may be required, as well.
  • Such Clearing Network Specific Information may also be stored by the TM 106 in a Clearing Network Specific Database 146 or in a separate database.
  • Fig. 4 is a simplified representation of the System 100 of Fig. 1, showing one second entity 102a, the Platform 104, an Institution 105a, the Transaction Manager 106 and the Clearing Network 112, as well as certain of the file transfers and file conversions discussed herein.
  • Fig. 5 is an example of a method of operation 200 of the Financial Transaction Clearing System 100 of Fig.1.
  • entity 102a sends a Transaction File containing details related to one or more transactions with respective entities lOla-lOln, to be settled.
  • the entity 102a may be a POS merchant, for example, and the Transaction File may contain all the credit card and debit card transactions in the preceding day, for example.
  • the Platform 104 analyzes and processes the Transaction File, in Step 204. Analysis and processing may include analyzing the Transaction File for transactions with enors, such as incomplete or enoneous data. Errors may be caused by telecommunications error, software error, input error, etc. Transactions with one or more errors may be removed from the Transaction File, or the entire File may be rejected. A Reject File on that transaction may be provided to the respective entity, 102a-102n, who may correct the enors and send the transaction again in a new Transaction File.
  • enors such as incomplete or enoneous data. Errors may be caused by telecommunications error, software error, input error, etc. Transactions with one or more errors may be removed from the Transaction File, or the entire File may be rejected. A Reject File on that transaction may be provided to the respective entity, 102a-102n, who may correct the enors and send the transaction again in a new Transaction File.
  • the Platform 104 may also identify the fransactions of the Transaction File as being a U.S. fransaction, in which the currency of the transaction is U.S. dollars and the bank account of the entity 102a is in the U.S., or an international transaction, in which the cunency is not U.S. dollars and/or the bank account of the entity 102a is not in the U.S., in Step 206.
  • the Platform 104 generates a Basic Funding File comprising a respective Detail Record conesponding to a transaction, including an identifier to classify the transaction as a U.S. or international transaction.
  • each Detail Record includes a cash value for the amount of cash to be fransferred in each respective transaction.
  • the Basic Funding File preferably includes a total cash value for all the Detail Records. This total may be in a Trailer Record of the File, for example. (The format of the Basic Funding File is discussed further, below.)
  • the Basic Funding File typically includes transactions from a plurality of entities 102a- 102n, for a particular time period.
  • the Basic Funding File is sent to a processor, such as the TM 106, in Step 208.
  • Fig. 6 is an example of a method 300a of managing transactions in accordance with an embodiment of the invention, which may be implemented by the TM 106, for example.
  • the Basic Funding File provided by the Platform 104 in Step 208 is received by the TM 106, in Step 302.
  • the TM 106 calculates hash totals of the Basic Funding File, in Step 304.
  • Hash totals may be calculated by summing the monetary amounts in each Detail Record in the File and comparing that value to the total cash value for all Detail Records in the File. If the hash totals do not match, the File is rejected in Step 308 and a Reject File is generated and sent to the Platform 104, in Step 310. The Platform 104 may then correct the File and send it back to the TM 106. If the hash totals match, a Confirmation File is generated and sent to the Platform 104, to inform the Platform that the Basic Funding File has been accepted for further processing, in Step 311.
  • the TM 106 is preferably programmed to compare information previously provided by the Platform 104 to information in the Detail Records.
  • the processor 132 may compare expected information concerning a respective second entity 102a-102n identified in each Detail Record to information about the respective entity in the Identifying Information Database 138. If there are differences between the information in the Detail Record about the respective second entity 102a-102n and the expected information, in Step 314, the Detail Record is flagged, in Step 316.
  • the second entity associated with the flagged Detail Record and the change may then be stored by the processor 132 in the Database 138a, for example.
  • the Detail Record may then be rejected in Step 318.
  • the method may then return to Step 310 to generate a Reject File identifying the rejected Detail Record and describing the identified change with respect to that Detail Record and the Reject File is sent to the Platform 104.
  • the Platform 104 may then investigate the changes to determine if the changes were made in pursuit of fraud.
  • the TM 106 may tolerate minor changes, such as a change of name of the second entity, particularly if it is the first time such a change occuned.
  • the method 300a may proceed to Step 320, as shown in phantom.
  • each Detail Record for each transaction in the Basic Funding File is analyzed for data enors, such as incomplete or missing information, improper, incomplete or mistaken codes, improper formatting of information, etc. in Step 320.
  • the processor 132 may check each field in each Detail Record in the Basic Funding File and accumulate a count of enors.
  • Data enors and identity changes in Detail Records in the Basic Funding File that may be identified by the TM 106 may include:
  • Second Entity's International Bank Code is Blank Second Entity's Local Branch Code is Blank
  • Second Entity's Bank Information has Changed Second Entity's Contact Information has Changed
  • Second Entity's Contact Name is Blank Second Entity's Contact City is Blank
  • Second Entity's Contact Country Code is Blank
  • two bases are provided for rejection related to the decimal places.
  • One rejection occurs if the number of decimal places of the amount does not match the number of decimal places defined in the Cunency Table in the Database 142. For example, the Cunency Table database indicates that Yen should have no decimal places. If a decimal place is indicated, the Detail Record is rejected.
  • no more than two decimal places are preferably used in the TM 106. If more than two decimals places are provided, the processor 132 preferably rounds the value off to two decimal places and continues to process the Detail Record. The processor 132 also preferably informs the Platform 104 so that in the future, the Platform provides no more than two decimal places.
  • Step 321 it may still be advantageous to continue to process the Basic Funding File, so that the processing of Detail Records without enors is not delayed. It is therefore preferred to determine whether the number of Detail Records with enors exceed a threshold, in Step 322. If so, the Basic Funding File is rejected, in Step 308.
  • a Reject File is generated and sent to the Platform 104, in Step 310.
  • the Reject File identifies the Detail Record with the error or enors, and identifies the enors.
  • the Platform 104 may conect the errors and send those Detail Records back to the TM 106 in a new Basic Funding File.
  • Step 324 If the number of enors is less than the enor threshold, the Detail Records containing enors, if any, are removed from the File, in Step 324, and a Reject File is generated and sent to the Platform 104, identifying the rejected Detail Records and the reasons for the rejection, in Step 310. Processing of the Basic Funding File continues in Step 326.
  • the threshold applied by the TM 106 may be dependent upon the size of the file. For example, large files, greater than about 10 transactions, for example, may have a smaller threshold than smaller files. A large file may have a threshold of 5% while a smaller file may have a threshold of 10%, for example.
  • a Clearing Network 112, 112a . . . 112n is selected for clearance and settlement of the money transfer in each Detail Record, and added to the Detail Record.
  • a Clearing Network 112, 112a . . . 112n may be selected by the processor 132 based on the information in the Clearing Network Specific Database 146, or may have been selected by the second entity 102a, as discussed above.
  • a Worldwide Funding File is generated comprising Detail Records formatted in an appropriate format, in Step 328.
  • Method 400 of Fig. 7 is an example of a method for generating the Worldwide Funding File, in Step 328. It is first determined whether the selected Clearing Network 112 requires that the Detail Records in the Worldwide Funding File be in a particular format, in Step 402. For example, as discussed above, ABN AMRO requires that the File be in UN/EDIFACT format, whether the Detail Record relates to U.S. or international fransactions. If so, the Worldwide Funding File is generated with Detail Records in the required format, in Step 404. If not, Detail Records are identified as being for U.S. or international transactions, Step 406.
  • a Worldwide Funding File of Detail Records of U.S. fransactions in a U.S. standard format is generated in Step 408.
  • the U.S. standard format is currently NACHA.
  • a Worldwide Funding File of Detail Records of international fransactions in an international standard format is generated in Step 410.
  • the international standard format is cunently UN/EDIFACT. Other formats may be used, as well.
  • the processor 132 is programmed to generate these files.
  • the TM 106 may make that determination here.
  • the processor 132 may make this determination based on the Country Code of the second entity's bank, for example, found in the Detail Record.
  • Step 338 the value date indicator for each Detail Record is preferably identified, the value date is calculated, and the value date is added to the Detail Record.
  • the value date indicator may be identified by the processor 132 in each Detail Record.
  • the processor 108 may calculate the value date based on the cunent date, the value date indicator and other country specific information, such as whether banks in that country are opened on Friday, Saturday or Sunday. Such information ma be stored in the Country Specific Database 142 or another such database, as discussed above.
  • the counfry where the money is to be fransfened to is identified in Step 340, if it has not already been identified.
  • the counfry may be identified by the processor 132 via a Country Code in the Detail Record for the Worldwide Funding File or Basic Funding File, depending on when this step is conducted.
  • countries may have different information and formatting requirements for transaction processing and money transfer.
  • the UN/EDIFACT or other such international formatted Detail Records are therefore preferably modified and/or enhanced to include country specific information and country specific formatting requirements, in Step 342.
  • Country specific information and formatting requirements may be found by the processor 132 in the Country Specific Database 142, for example, based on the Country Code. If the UN/EDIFACT format is used for U.S. transactions by ABN AMRO, the counfry specific information and formatting added to the Detail Record is that of the NACHA format.
  • Country Specific Funding Files are formed in Step 344.
  • Detail Records for cash transfer to particular countries are provided in the same Counfry Specific Funding File.
  • a Country Specific Funding File may include Detail Records related to multiple countries, in which case Detail Records related to the same country would be organized in the same subfile within the Country Specific Funding File.
  • Country thresholds for cash transfer mode are identified for the country identified in Step 346.
  • the country thresholds for the country of each transaction may be found by the processor 108 in the Country Specific Threshold
  • Database 110a based on the Country Code for the bank where the bank account of the second entity 102a is located, in the Detail Record.
  • the mode of transferring the cash may then be added to the Detail Record, also in Step 346.
  • countries may establish cut-off time frames within which money transfers must be completed or the transfer defened until the next day.
  • the Country Specific Cut Off Time Frames are preferably identified, cut off times and dates are calculated and incorporated in the Country Specific Funding File, in Step 348.
  • Country Specific time frames may be found by the processor 108 in the Country Specific Time Frame Cutoff Database 144, based on the Country Code in the Detail Record. For U.S. transactions, cut off time frames for individual banks may also be found in the Database 144, based on the Bank or Bank Branch Code.
  • Additional Clearing Network Specific Information is incorporated in the Worldwide Funding File, in Step 350. Such information may also be found by the processor 132 in the Clearing Network Specific Database 146 or other such database in the TM 106, for example.
  • the Country Specific Funding File is checked for enors, in Step 352. Errors that may be found in this step include processing enors due to reformatting in the NACHA or UN/EDIFACT formats, inconect transaction amounts, misplacement of a decimal point, missing names of a bank or originating entity, etc. If there are enors, the method returns to Step 328 (Fig. 6) to repeat the processing required to create the Worldwide Funding File and Country Specific Funding File. ⁇
  • the Counfry Specific Funding File is sent to the selected Clearing Network 112, in Step 350.
  • the File is preferably sent via the interface 130b via a direct telecommunications connection between routers controlled by the TM 106, for security.
  • the File is also preferably encrypted by the TM 106 prior to sending, and is then decrypted by the TM 106 at the Clearing Network 112.
  • the method of operation 200 of the Financial Transaction Clearing System 100 continues in Step 210 of Fig. 9, where the Counfry Specific Funding File is received by the Clearing Network 112.
  • the Global Clearing Network 112 checks the Country Specific Funding File for enors, in Step 212.
  • the Clearing House 115 may perform this function, for example.
  • the following enors may cause rejection of the Country Specific Funding File by the Clearing Network 112: Second Entity's Account Number Unknown
  • the Network Beneficiary Bank 118a-l 18n may also analyze the Country Specific
  • the types of enors that may be identified by the Network Beneficiary Bank 118a-l 18n include withdrawal of authorization by the first or second entities 101a, 102a, and problems with funding or accounts, for example.
  • the following enors may cause rejection of the country Specific Funding File by the Network Bank 118a:
  • Step 214 the Detail Records with the enors are removed from the Country Specific Funding File, in Step 216 and a Reject File is generated and sent to the TM 106, in Step 218.
  • the Reject File identifies the rejected Detail Records and the enor or enors causing the rejection.
  • the TM 106 may conect the enors and send the Detail Records back to the Clearing Network 112 in another Country Specific Funding File.
  • a Confinnation File is also generated and sent to the TM 106, in Step 220, in either case.
  • the Confirmation File relates the number of accepted and rejected Detail Records from a Country Specific Funding File.
  • the Network Bank 118a If the Country Specific Funding File is acceptable, the Network Bank 118a generates a Control File and sends the file through the Clearing Network 112, to the TM 106, in Step 224.
  • the Control File summarizes the total cash value of all the money transfers in the File and the number of Detail Records in the File.
  • the Country Specific Funding File is sent to the Clearing Gateway 116 and an appropriate Network Bank 118a, for example, based on the counfry to which the money is to be moved, in Step 222.
  • a bank status message such as a BANSTA, is preferably generated and sent to the TM 106 by the Clearing Network 112, indicating that the file has been received by the appropriate Network Bank 118a, in Step 226.
  • a BANSTA is a message sent among financial institutions to provide status information about execution of instructions, for example, and is known in the art.
  • a positive Bank Status Message indicates that the Country Specific Funding File has been successfully fransfened and is accepted.
  • a negative Bank Status Message indicates that the File is not accepted and why.
  • the Clearing Network 112 generates a Transaction Journal including an account balance, such as a financial statement of an account ("FINSTA"), for each Cash Account 114a-l 14n dedicated to funding fransactions, in Step 224.
  • an account balance such as a financial statement of an account (“FINSTA")
  • the FINSTA shows the debits, credits and cunent balance of the account.
  • FINSTA statements are also known in the art.
  • the FINSTA or other such transaction journal is preferably generated periodically. It may be generated five times per day, for example.
  • method 300b is an example of another embodiment of the invention.
  • the Confirmation File is received in Step 352, the Control File is received in Step 354, the Bank Status Message is received in Step 356 and the Transaction Journal is received in Step 354. If any of these files are not received, the method does not continue and the TM 106 may contact the Clearing Network to inquire why. If all the files have been received but the Bank Status Message is not positive, in
  • Step 360 the TM 106 may address problems in the Country Specific Funding File and send it to the Clearing Network again in Step 362. If the Bank Status Message is positive, the processor 132 of the TM 106 compares the Transaction Journals to the Country Specific Funding File, in Step 364, to determine whether there are sufficient funds to settle the transactions in the File, in each currency, in Step 366. If there are sufficient funds in Step 366, the processor 132 generates and sends a Money Transfer File to cause an appropriate amount of cash to be moved from an appropriate one of the Cash Accounts 114a- 114n to an appropriate one of the In Country Accounts 119a-l 19n, in Step 370.
  • the cash is typically moved by wire transfer from the Cash Account 114a-l 14n to the In Country Account 119a- 119n.
  • the File may be sent to the Clearing Network 112 via FTP, for example. If it is determined that there are not sufficient funds of a particular currency in a Cash Account 114a-l 14n for that currency, in Step 366, the TM 106 may determine whether an overdraft line of credit may be relied upon, in Step 374. If the overdraft line of credit is available, settlement is authorized, in Step 370, by generation of the Money Transfer File, as discussed above.
  • Step 376 If an overdraft line of credit is not available, settlement is not authorized and the process is stopped with respect to this Country Specific Funding File, in Step 376.
  • TM 106 may instruct the Clearing Network 112 to delay settlement for a period of time, such as 24 hours, for example, in which time additional funds may become available in the settlement account.
  • Step 364 is returned to after the period of time, to again determine if sufficient funds are available, in Step 378.
  • the TM 106 may also order the fransfer of funds of the appropriate currency to the respective Cash Account 114a-l 14n from an appropriate Payment Source 108, for example, in Step 380.
  • Step 364 may then be returned to at an appropriate time to again determine if there are sufficient funds.
  • the method 200 continues in Fig.
  • Step 232 the Clearing Network 112 conveys the Money Transfer File to the Bank 113, to cause transfer of cash from an appropriate Cash Account 114a-l 14n to an appropriate In Country Account 119a-l 19n in Step 234, as discussed above.
  • the total amount of cash identified in the Money Transfer File in the proper currency is fransfened from an appropriate one of the Cash Accounts 114a-l 14n, in this example Account 114a, or the Payment Source 108, to an appropriate one of the In Country Accounts 119a-l 19n, here Account 119a, in a manner known in the art, in Step 244.
  • the money may be fransfened by wire transfer, for example, which is known in the art.
  • the cash is then fransfened to the appropriate one of the Network Banks 118a- 118n, here 118a, in Step 246.
  • the cash may be fransfened by low value clearing or by wire transfer, as determined by the TM 106 based on country thresholds, as discussed above. If the second entity's bank account is found to be with the Network Bank 118a, in Step 248, the cash is put into that account, in Step 250.
  • a bank status message such as a BANTSA, is generated and sent to the TM 106, in Step 252.
  • the BANTSA may be provided from the Network Beneficiary Bank 118a to the TM 106, via the Clearing Network 112. If the second entity 102a does not have an account with the Network Beneficiary Bank 118a, the Network Beneficiary Bank will send the Settlement File to the Local Beneficiary Bank 120a-120n where the entity has an account, here, Local Beneficiary Bank 120a, as is known in the art. The transfer may take place by low value clearing or by wire transfer, as determined by the TM 106 based on the counfry threshold. The Local Beneficiary Bank 120a may also check the Cash Payment File for enors. If the File is acceptable, funds are fransfened from the Network Beneficiary Bank 118a to the second entity's account at the Local Beneficiary Bank 120a.
  • the Local Beneficiary Bank 120a will inform the Clearing Network 112 whether the cash has been successfully fransfened or not, in Step 256.
  • the Clearing Network 112 will generate and send the Bank Status Message to the TM 106, in Step 252, as described above.
  • the TM 106 generates a Status File for each Detail Record provided to the Clearing Network 112, based on the Confirmation File, Control File, Transaction Journal and Bank Status Message received from the Clearing Network 112, after the cash has been fransfened to the bank account of the second entity 102a, or an attempt to transfer the money has been made.
  • the Transaction Journal indicates whether the transfer has been successful or not.
  • the Status File is a detailed flow summary of the steps in the clearance and settlement process and the times the events took place.
  • the Status File is provided to the Platform 104 and preferably to the appropriate Institution 105a-105n associated with that Detail Record, as well.
  • the Platform 104 may then inform a respective second entity 102a-102n whether the money has been transferred or not
  • the Status File preferably contains the necessary information to describe an event related to the processing of the Country Specific Funding File by the TM 106 and the Clearing Network 112a, to the Platform 104.
  • the events that may be reported include, for example, acceptance or rejection of the Country Specific Funding File by a Network Beneficiary Bank 118a-l 18n, payment to the second entity's account in the Network or Local Beneficiary Bank 118a-l 18n, 120a-120n, an unsuccessful attempt to pay the Network or Local Beneficiary Bank 118a-l 18n, 120a-120n and return of the Country Specific Funding File to the TM 106 due to enors.
  • the Status Files may be organized by date, Platform 104 and Institution 105a-105n. Fig.
  • the Transaction Journal is received by the TM 106, in Step 390.
  • the Confirmation File, Control File, Bank Status Message and Transaction Journal are processed, in Step 392.
  • a Status File is generated, in Step 384, and sent to the Platform 104 and appropriate Institution 105a-105n, in Step 396.
  • the File may be sent via FTP, for example.
  • the Status File may be generated by the processor 132.
  • the respective second entity 102a-102n may then post the payment to their accounts receivable.
  • the Platform 104 may also create an accounts receivable and offset the amount of the fransfened money on the entity's general ledger. Previously, payments have assumed or second entities 102a-102n have had to monitor their accounts.
  • the TM 106 preferably gives access to Institutions 105a-105n to information about the status of the progress of particular Detail Records that they are associated with.
  • the Detail Records may have an identification of the respective one of the Institutions 105a-105n, here 105a, associated with the underlying transaction.
  • the Institution 105a only has access to the information about the Detail Records that include an identifier of that Institution.
  • the Institution 105 a may thereby obtain current information about the status of the processing of those Detail Records, including identification of rejected Detail Records and the reason for the rejection, and the progress of the associated cash transfer through the Clearing Network 112, based on the information and files provided by the Clearing Network 112 to the TM 106.
  • the status related information may be in the program software itself, in memory 136.
  • the Institution 105 a may access the information in the program on the TM 106 via emulation software, such as 5250 emulation software, which is commercially available.
  • the Institution 105a may view accessed information on a PC in its own facility, for example.
  • the Institution 105a may have a user identification and a password, for security.
  • Fig. 13 is an example of a method 450 for the TM 106 to grant access to information to an Institution 105a-105n, in accordance with another embodiment of the invention.
  • a request for access is received from an Institution, here Institution 105a, including a proper user name and password, in Step 452.
  • An Institution Identification (“JED") and a Detail Record Identification (“ID”) are received, in Step 454.
  • the Institution ID may have been received with the initial request during sign in Step 452.).
  • the Institution ID and the Detail Record conesponding to the Detail Record JED are compared to determine whether the Jhistitution is associated with that Detail Record, in Step 456.
  • the Detail Record may include the Institution ID of its associated Institution, for example, which may be checked by the processor 132. If it is determined that the Institution 105a is not associated with the requested Detail Record in Step 458, the request for access is denied in Step 458. If the Institution 105a is found to be associated with the requested Detail Record, access is granted, in Step 460.
  • the Institution 105a can then view the current information about the Detail Record on a PC at its own facility, for example.
  • the files preferably comprise a File Header Record, File Detail Records and a File Trailer Record.
  • the File Header Record of the Basic Funding File may contain the fields identified below in Table I, for example: TABLE I - FILE HEADER RECORD
  • the File Sequence Number may be used, in conjunction with the File Create Date, to uniquely identify each Basic Funding File and to identify duplicate transmissions.
  • each Detail Record of the Basic Funding File relates to a single money transfer transaction.
  • Each Detail Record comprises a Record JED ("FD") to uniquely identify the Detail Record.
  • the Record also comprises an Entity JED Number to identify the second entity 102a-102n to the transaction of that Detail Record, a Trade Name of the second entity, Account and Address details of the second entity, a Monetary Amount of the transaction, a Counfry Code of the country where the second entity's bank account is located based on International Standard Organization (“ISO”) 3166 and a Cunency Code of the currency of the transaction.
  • a Transaction (“TJXN) Reference Number is generated by the Platform 104 to identify each fransaction in the Transaction File provided to the Platform 104 by the second entities 102a-102n.
  • the File Trailer Record of the Basic Funding File may comprise a Record ID ("FT") to identify the File Trailer Record.
  • the File Trailer Record may also comprise a Transaction Total, which is the total number of Detail Records in the file, and an Amount Hash Total, which is the total of all the money transfers in the file. This total may be used to check high totals, as described above.
  • the File Header Record of the Status File may comprise a Record ED of the File, a Sender ID, a Receiver ID, a File Create Date and Time, a Sequence Number and an Institution ID, which have been discussed above.
  • the File Trailer Record may comprise a Record JED and a Record Total identifying the number of Detail Records in the Status File.
  • Each Detail Record may comprise the following fields, for example: TABLE III - STATUS FILE DETAIL RECORD
  • the Basic Funding File may be used to both credit an account of a Second Entity 102a, for example, as well as to debit an account of a First Entity 101a, for example.
  • the Transaction Type field in the Detail Record (Table II, above), is used to indicate whether the transaction is a credit or debit transaction. If it is a debit transaction of the First Entity 101a, a conesponding Basic Funding File defining the credit to the Second Entity 102a.
  • Table IN is an example of a schedule of file delivery dates for selected European countries, where the Clearing Network is ABN AMRO.
  • D refers to the payment date.
  • D-l, D-2, D-3 are one, two and three days prior to the payment date, respectively.
  • the first column indicates the number of days prior to payment that a file must be delivered to the Clearing Network.
  • the second column indicates the number of days prior to payment that the TM 106 may provide the Counfry Specific Funding File to the Clearing Network 112.
  • the third column indicates when the file needs to be delivered to the Clearing Gateway 115 of the Network 112 in order for payment to be rendered on the proper day D, indicated in the fourth column.
  • the TM 106 may provide the Country Specific Funding File one day earlier than is required. In some countries, such as Denmark and Finland, the TM 106 may provide the Country Specific Funding File two days earlier than is required. The ability to provide the Country Specific Funding File to the Clearing Network 112 one day early may enable faster payment. TABLE IV

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Finance (AREA)
  • Computer Security & Cryptography (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Technology Law (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

L'invention concerne un procédé de traitement d'un transfert de liquidités par ou à charge d'un premier établissement sur le compte bancaire d'un second établissement consistant à recevoir l'information concernant le transfert de liquidités et à formater l'information en une pluralité de formats d'après, au moins partiellement, un emplacement du compte bancaire. L'information peut être formatée selon un format NACHA, si le compte bancaire se trouve aux Etats-Unis, ou en format UN/EDIFACT, si le compte bancaire ne se trouve pas aux Etats-Unis. L'information associée au pays dans lequel se trouve le compte bancaire peut être ajoutée à l'information formatée afin de faciliter et de permettre la compensation et l'acquittement de fonds dans ce pays. Un réseau de compensation peut être sélectionné pour la compensation et la liquidation des fonds. L'information concernant le second établissement peut être reçue et mémorisée au préalable dans une mémoire, en vue de sa comparaison avec une information reçue couramment concernant le second établissement dans une transaction actuelle, et ce de manière à détecter les fraudes. Font également l'objet de cette invention des systèmes associés.
EP03774754A 2002-10-07 2003-10-07 Procede et systeme de gestion de transactions financieres Ceased EP1559044A4 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US41666302P 2002-10-07 2002-10-07
US416663P 2002-10-07
PCT/US2003/032124 WO2004034222A2 (fr) 2002-10-07 2003-10-07 Procede et systeme de gestion de transactions financieres

Publications (2)

Publication Number Publication Date
EP1559044A2 EP1559044A2 (fr) 2005-08-03
EP1559044A4 true EP1559044A4 (fr) 2007-11-07

Family

ID=32093882

Family Applications (1)

Application Number Title Priority Date Filing Date
EP03774754A Ceased EP1559044A4 (fr) 2002-10-07 2003-10-07 Procede et systeme de gestion de transactions financieres

Country Status (4)

Country Link
EP (1) EP1559044A4 (fr)
AU (1) AU2003282567A1 (fr)
CA (1) CA2501646A1 (fr)
WO (1) WO2004034222A2 (fr)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8239319B2 (en) 2004-03-22 2012-08-07 The Western Union Company Equipment to facilitate money transfers into bank accounts
US8930267B1 (en) 2012-08-27 2015-01-06 Jpmorgan Chase Bank, N.A. Automated transactions clearing system and method

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7664703B2 (en) * 1999-10-26 2010-02-16 The Western Union Company Value transfer systems and methods
US7104440B2 (en) * 1999-10-26 2006-09-12 First Data Corporation Money transfer systems and methods for travelers
US7849009B2 (en) * 1999-12-29 2010-12-07 The Western Union Company Methods and apparatus for mapping sources and uses of consumer funds
WO2001050304A2 (fr) * 1999-12-29 2001-07-12 Paymap, Inc. Procede et appareil de mappage de sources et d'utilisations de fonds de consommateurs
US20030126075A1 (en) * 2001-11-15 2003-07-03 First Data Corporation Online funds transfer method
EP1451741A2 (fr) * 2001-11-26 2004-09-01 Epacific Inc. Systemes et procedes de transfert de fonds

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
No Search *

Also Published As

Publication number Publication date
WO2004034222A2 (fr) 2004-04-22
EP1559044A2 (fr) 2005-08-03
AU2003282567A1 (en) 2004-05-04
AU2003282567A8 (en) 2004-05-04
CA2501646A1 (fr) 2004-04-22
WO2004034222A3 (fr) 2004-06-03
WO2004034222A9 (fr) 2004-07-08

Similar Documents

Publication Publication Date Title
US20040128240A1 (en) Method and system for managing financial transactions
US11205160B2 (en) Electronic payment and authentication system with debit and identification data verification and electronic check capabilities
US7395241B1 (en) Consumer-directed financial transfers using automated clearinghouse networks
US7333953B1 (en) Method and apparatus for integrated payments processing and decisioning for internet transactions
US7912784B2 (en) Methods and systems for processing, accounting, and administration of stored value cards
US7103577B2 (en) Systems and methods for staging transactions, payments and collections
US7848977B2 (en) Private label purchase card acceptance systems and methods
US8150763B2 (en) Systems and methods for staging transactions, payments and collections
US20030135457A1 (en) Method and apparatus for providing online financial account services
US20060229961A1 (en) Risk evaluation method and system using ACH data
US8109435B2 (en) Identity verification switch
US20050177494A1 (en) Method and system for processing electronic financial transactions
US20030061156A1 (en) Instant settlement system and method for credit card member stores
US20070124242A1 (en) Funds transfer system
US20050192892A1 (en) Automated clearing house compatible loadable debit card system and method
WO2001039589A2 (fr) Procede et appareil pour fournir des services de comptes financiers en ligne
WO2001084276A2 (fr) Systeme et procede internationaux de paiement
KR20010082133A (ko) 기업간 대금결제 관리 시스템 및 이를 이용한 기업간대금결제 관리 방법
CA2479333A1 (fr) Methode et systeme d'indemnisation des marchands pour des transactions financieres en ligne
US20060143124A1 (en) Real time payment transaction system and method
US20060036540A1 (en) Method and system for merchant indemnification for online financial transactions
EP1559044A2 (fr) Procede et systeme de gestion de transactions financieres

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20050504

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LI LU MC NL PT RO SE SI SK TR

AX Request for extension of the european patent

Extension state: AL LT LV MK

DAX Request for extension of the european patent (deleted)
A4 Supplementary search report drawn up and despatched

Effective date: 20071005

17Q First examination report despatched

Effective date: 20080509

REG Reference to a national code

Ref country code: DE

Ref legal event code: R003

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED

18R Application refused

Effective date: 20110711