US20070094151A1 - Systems and Methods of Rules-Based Database Access For Account Authentication - Google Patents

Systems and Methods of Rules-Based Database Access For Account Authentication Download PDF

Info

Publication number
US20070094151A1
US20070094151A1 US11/612,254 US61225406A US2007094151A1 US 20070094151 A1 US20070094151 A1 US 20070094151A1 US 61225406 A US61225406 A US 61225406A US 2007094151 A1 US2007094151 A1 US 2007094151A1
Authority
US
United States
Prior art keywords
database
account
information
association
account holder
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.)
Abandoned
Application number
US11/612,254
Inventor
Peter Moenickheim
Paul Lyda
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.)
Individual
Original Assignee
Individual
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 Individual filed Critical Individual
Priority to US11/612,254 priority Critical patent/US20070094151A1/en
Publication of US20070094151A1 publication Critical patent/US20070094151A1/en
Abandoned legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/02Banking, e.g. interest calculation or account maintenance
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/085Payment architectures involving remote charge determination or related payment systems
    • G06Q20/0855Payment architectures involving remote charge determination or related payment systems involving a third party
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/382Payment protocols; Details thereof insuring higher security of transaction
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/40Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401Transaction verification
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/40Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401Transaction verification
    • G06Q20/4012Verifying personal identification numbers [PIN]

Definitions

  • the present invention relates to electronic commerce, and more particularly to authentication of deposit account information.
  • On-line payment service providers make payments on behalf of payors to payees.
  • an on-line payment service provider debits a deposit account belonging to the payor and issues a credit to the payee, either electronically, by check drawn on an account belonging to the on-line service provider, or by draft drawn from the payor's deposit account. It will be understood by one skilled in the art that drafts serve as both the debit and the credit vehicle.
  • a payor must register with an on-line payment service provider to access services offered by the on-line payment service provider.
  • the registration process which can be either on-line, typically via the World Wide Web, or by paper forms, includes the payor (registering customer) providing information identifying a demand deposit account, such as a checking account, belonging to the payor to the on-line payment service provider.
  • This identifying information includes a unique routing and transit number (RTN), which identifies the financial institution at which the deposit account is maintained, as well as a unique account number (DDA) identifying the payor's deposit account maintained at the financial institution. Together, this information is known as RTN/DDA information, and alternatively RT/DDA information.
  • the registering customer has conventionally been required to supply the on-line payment service provider a voided check from the deposit account.
  • This voided check is used as a fraud prevention measure to authenticate the association between the registering customer and the deposit account.
  • a registering customer has not been able to immediately direct an on-line payment service provider to make payments on his or her behalf, as the voided check must physically be delivered to the on-line payment service provider, and then the voided check must be authenticated by a customer service representative of the on-line payment service provider.
  • a trusted agent typically a consumer service provider (CSP)
  • CSP consumer service provider
  • the registering customer's identity is verified, by leveraging one or more commercial databases, while the registering customer is participating in an on-line registration session. While the registering customer's identity is verified, an association between the registering customers deposit account and the registering customer is not authenticated. At most, the on-line payment service provider can be assured that the registering customer is who he or she purports to be. Based upon a verified identity, on-line payment service providers have found that there is less chance of the registering customer providing fraudulent information identifying a deposit account.
  • a registering customer In both of these completely on-line and real-time techniques, a registering customer is required to enter RTN/DDA information. As the registering customer is not required to supply a voided check, the sole source of this information is the registering customer.
  • On-line payment services have found that registering customers often make mistakes in entering these numbers. On-line payment services, in rectifying these unintentional mistakes, incur customer service costs. In addition, fraudulent deposit account identifying information is also still received under both completely online registration techniques. Even when a CSP indemnifies an on-line payment service, costs are still associated with the fraud.
  • a financial institution at which a customer's account is maintained supplies RTN/DDA information. While an association between a customer and an account is authenticated because the financial institution itself supplies RTN/DDA information, this does not occur during an on-line and real-time enrollment session with a customer.
  • a registering customer provides RTN/DDA information during an on-line session.
  • a service provider makes one or more small debits and/or credits, via electronic funds transfer, from/to the customer's account. The customer then determines the amount(s) and initiates another on-line session with the service provider and identifies the amount(s) to the service provider.
  • the service provider has a high level of confidence that the account is actually associated with the registering customer.
  • the enrollment process can not be completed fully in a single session, as the consumer must take some action (determining the amount(s)) subsequent to an initial registration session.
  • Some on-line payment services access more than one commercial database in the registration process in attempting to locate information used to authenticate a registering customer's identity (not to authenticate an association between a customer and a deposit account).
  • an on-line service provider must access multiple commercial databases before useful information is found. These commercial databases charge for access, making this an expensive process.
  • FIG. 1 depicts a computing system maintained by an electronic commerce service provider.
  • FIG. 2 depicts the processing to authenticate an association between a deposit account and a registering customer.
  • FIG. 1 shows an electronic commerce service system 100 maintained by an electronic commerce service provider (hereinafter, service provider). Included in system 100 is a processor 105 which is driven by instructions stored in memory 110 . Processor 105 could be multiple processors working either in concert or independently to provide the functionality described herein. Likewise, memory 110 could be multiple memories. Processor 105 includes a rules engine 107 and a matching engine 108 , which will be discussed below. Also shown is a communications interface 115 for communicating with registering customers and other entities. Though only one communications interface 115 is depicted, it should be understood that multiple communications interfaces could be included in system 100 .
  • service provider electronic commerce service provider
  • Memory 110 in addition to storing the above described instructions, also stores a historical database 150 which stores information associated with registrations of each of multiple registering customers, data accumulated during provision of electronic commerce services, as well as other information used to determine which external databases (described below) to access during an on-line and real-time registration session. It will be appreciated that registration processing could be performed as a batch process. That is, not in real-time.
  • FIG. 1 Also depicted in FIG. 1 , though not necessarily a part of system 100 , are multiple external databases 160 A- 160 N. These external databases store information gathered by entities other than the service provider. Information stored in these external databases 160 A- 160 N is utilized to authenticate an association between a registering customer and a deposit account.
  • These external databases 160 A- 160 N belong to any one of, or any combination of, check printing services, check verification services, check guarantee services, and financial institutions.
  • check printing services are Deluxe, Harland, and Clark American, though other check printing services' databases could also be accessed.
  • check verification and/or guarantee services are Telecheck and Equifax Check Services, though other check verification and/or guarantee services' databases could also be accessed.
  • a financial institution maintains deposit accounts on behalf of depositors, in addition to providing other financial services.
  • a financial institution obviously, has knowledge of associations between accounts that financial institution maintains and depositors (customers).
  • a financial institution may have knowledge about associations between accounts and depositors for accounts that are maintained at other financial institutions.
  • Information stored in external database 160 A- 160 N is associated with deposit accounts.
  • Check printing services retain information associated with each check order printed for an account holder. This information is typically retained so that a subsequent check order for the account holder can be printed without all account holder identifying and account identifying information being supplied a second time in order to print the second order. Thus, check printing services maintain information that authenticates an association between an account holder and an account.
  • one or more of the external databases 160 A- 160 N could be hosted by the service provider.
  • a third party such as a check printing, verification, or guarantee service, would provide information to be stored to the service provider.
  • the service provider would then access the service provider hosted external database(s) as necessary.
  • a registering customer provides, during an on-line enrollment session, preferably via a World Wide Web interface 201 , identifying information 105 such as one or more of name, drivers license number, and social security number to system 100 .
  • This information is received by communications interface 115 . Any or all of this identifying information could be provided, in addition to other forms of identifying information.
  • the registering customer also provides RTN/DDA information identifying a deposit account which they are authorizing the service provider to access. It should be noted that identifying information could be received from an entity other than a registering customer, such as a sponsor. Sponsors provide access to electronic commerce services on behalf of customers.
  • This received information is then processed by the rules engine 107 while the registering customer is still participating in the on-line enrollment session.
  • the rules engine 107 first determines if historical database 150 contains information upon which a positive authentication between the registering customer and the customer's deposit account can be based. If so, the on-line registration session can be successfully completed without accessing commercial databases.
  • the rules engine 107 determines which of external databases 160 A- 160 N to access to authenticate an association between the registering customer and a deposit account. Criteria that can be used by the rules engine 107 in determining which external database to access includes the registering customer's financial institution's RTN (ABA) number. This information can be used because, based upon the historical information stored in the historical database 150 , it is known that certain financial institutions utilize certain check printing services.
  • ABA RTN
  • Other criteria that can be utilized to determine which of the external databases 160 A- 160 N to access includes geographic criteria, such as the location of the registering customer and/or his or her financial institution. Yet another criteria is cost. That is, fees charged by entities maintaining external databases 160 A- 160 N for accessing different ones of the external databases 160 A- 160 N vary among the external databases. Still another criteria is a success rate of particular ones of the external databases 160 A- 160 N in providing information useful in the registration process.
  • the rules engine 107 determines an order in which to access the external databases 160 A- 160 N. Once the rules engine 107 determines the order in which the external databases 160 A- 160 N should be accessed, the first determined external database is accessed in an attempt to locate information upon which to base an authentication determination.
  • the second determined external database is accessed. This process continues until information is found. It should be noted that if information for successful authentication information is not found in any database or other data store, the registering customer could be given the opportunity, on-line and in-session, to resubmit account identifying information, in view of the chance that the registering customer may have provided incorrect identifying information beforehand.
  • the matching engine 108 uses the matching engine 108 to authenticate the RTN/DDA information received from the registering customer. That is, the matching engine 108 compares the RTN/DDA information and the identity information received from the registering customer with data stored in the external database. If the received data matches that supplied by the registering customer, the association is successfully authenticated.
  • the registering customer Upon successful authentication, the registering customer is informed, via the on-line registration session, that registration is successful.
  • the registering customer becomes a registered customer.
  • the service provider can immediately and in-session provide services to the registered customer with confidence that an authentic association between the registered customer and a deposit account identified by that customer is in fact authentic.
  • the registering customer would be required to complete the registration process by traditional techniques. This could include, for instance, requiring the registering customer to supply a voided check to the service provider, as well as any other known registration technique.
  • each of external databases 160 A- 160 N are accessed, in the same determined order as above, and an authentication attempt is made against data stored in each external database.
  • the first determined external database is accessed, and based upon data stored in that database an authentication attempt is made. If that authentication attempt is unsuccessful, the second determined external database is accessed and another authentication attempt is made. This process continues until a successful authentication is made, or until each database has been accessed. As above, if on-line authentication is unsuccessful, the registering customer would have to complete the registration process in an off-line fashion.
  • external databases 160 A- 160 N could be accessed in a random order.
  • an entity to whom an external database belongs might not offer direct access to the information stored in the database.
  • the service provider transmits at least a portion of the received identifying information as well as the RTN/DDA information to the entity to whom the external database belongs. That entity then compares this received information with information contained in the database.
  • the match key could be one of four types: Account Found-Full Match, Account Found-No Match, Account Not Found, and Account Found-Possible Match. If the match key is of the Account Found-Full Match type, the authentication is successful. If the match key is of either the Account Found-No Match or Account Not Found types, the authentication is not successful and conventional, off-line, authentication techniques could be utilized. If the match key is of the Account Found-Possible Match type, further on-line activity can be performed to complete the authentication.
  • This further activity could include the service provider providing further received identifying information to the entity to whom the database belongs, and could include the service provider querying the registering customer, via the still active on-line session, for additional identifying information, which would then be transmitted to the entity to whom the database belongs for further processing.
  • the returned Match Key could be processed with other information to make the determination that authentication is successful or not. This other information could belong to the entity receiving the Match Key, or another entity. Also, instead of being processed with other information, a returned Match Key could be just one factor considered when making a determination as to a successful or unsuccessful authentication.
  • the inventive technique of on-line authentication of RTN/DDA information could be performed by the service provider on behalf of an entity other than the service provider.
  • This authentication process could be performed in real-time, via perhaps a Web-based interface or a direct connection between another entity and the service provider, or could be performed as an asynchronous (e.g. batch file based or messaging-based) process for another entity.
  • asynchronous e.g. batch file based or messaging-based

Abstract

Systems and methods for authenticating a customer association with a particular deposit account used when conducting financial transactions on behalf of the customer. The system receives identity information and routing and transit number or account number (RTN/DDA) information, where at least a portion of identity information identifies an account holder and at least a portion of the RTN/DDA information identifies a deposit account. A selection of numerous databases used to authenticate an association between the deposit account and the account holder is made based on one or more criteria. A database is then accessed according to the selection; and an association between the deposit account and the account holder is authenticated using the received identity information and RTN/DDA information and the selected database.

Description

    CROSS REFERENCE TO A RELATED APPLICATION
  • This application is a continuation of pending U.S. application Ser. No. 10/206,239, filed Jul. 29, 2002, entitled “Technique For Account Authentication,” the disclosure of which is incorporated by reference herein in its entirety.
  • FIELD OF THE INVENTION
  • The present invention relates to electronic commerce, and more particularly to authentication of deposit account information.
  • BACKGROUND OF THE INVENTION
  • On-line payment service providers make payments on behalf of payors to payees. In making a payment on behalf of a payor, an on-line payment service provider debits a deposit account belonging to the payor and issues a credit to the payee, either electronically, by check drawn on an account belonging to the on-line service provider, or by draft drawn from the payor's deposit account. It will be understood by one skilled in the art that drafts serve as both the debit and the credit vehicle.
  • A payor must register with an on-line payment service provider to access services offered by the on-line payment service provider. The registration process, which can be either on-line, typically via the World Wide Web, or by paper forms, includes the payor (registering customer) providing information identifying a demand deposit account, such as a checking account, belonging to the payor to the on-line payment service provider. This identifying information includes a unique routing and transit number (RTN), which identifies the financial institution at which the deposit account is maintained, as well as a unique account number (DDA) identifying the payor's deposit account maintained at the financial institution. Together, this information is known as RTN/DDA information, and alternatively RT/DDA information.
  • For both on-line and paper registration, the registering customer has conventionally been required to supply the on-line payment service provider a voided check from the deposit account. This voided check is used as a fraud prevention measure to authenticate the association between the registering customer and the deposit account. Thus, in conventional enrollment, a registering customer has not been able to immediately direct an on-line payment service provider to make payments on his or her behalf, as the voided check must physically be delivered to the on-line payment service provider, and then the voided check must be authenticated by a customer service representative of the on-line payment service provider.
  • Recently, new completely on-line and real-time registration techniques have been introduced. In one, a trusted agent, typically a consumer service provider (CSP), guarantees to indemnify an on-line payment service provider against fraud committed by a registering customer that the CSP represents. No attempt is made by the on-line service provider to authenticate the association between the registering customer and that registering customer's deposit account.
  • In another completely on-line and real-time registration technique, the registering customer's identity is verified, by leveraging one or more commercial databases, while the registering customer is participating in an on-line registration session. While the registering customer's identity is verified, an association between the registering customers deposit account and the registering customer is not authenticated. At most, the on-line payment service provider can be assured that the registering customer is who he or she purports to be. Based upon a verified identity, on-line payment service providers have found that there is less chance of the registering customer providing fraudulent information identifying a deposit account. These two techniques each allow a registering customer the convenience of immediately directing payments.
  • In both of these completely on-line and real-time techniques, a registering customer is required to enter RTN/DDA information. As the registering customer is not required to supply a voided check, the sole source of this information is the registering customer. On-line payment services have found that registering customers often make mistakes in entering these numbers. On-line payment services, in rectifying these unintentional mistakes, incur customer service costs. In addition, fraudulent deposit account identifying information is also still received under both completely online registration techniques. Even when a CSP indemnifies an on-line payment service, costs are still associated with the fraud.
  • Other new registration techniques have also been introduced. These techniques are not completely on-line or real-time. In one technique, a financial institution at which a customer's account is maintained supplies RTN/DDA information. While an association between a customer and an account is authenticated because the financial institution itself supplies RTN/DDA information, this does not occur during an on-line and real-time enrollment session with a customer. In another technique, a registering customer provides RTN/DDA information during an on-line session. Subsequent to the session, a service provider makes one or more small debits and/or credits, via electronic funds transfer, from/to the customer's account. The customer then determines the amount(s) and initiates another on-line session with the service provider and identifies the amount(s) to the service provider. If the customer supplied amount(s) is/are correct, the service provider has a high level of confidence that the account is actually associated with the registering customer. However, the enrollment process can not be completed fully in a single session, as the consumer must take some action (determining the amount(s)) subsequent to an initial registration session.
  • Accordingly, a need exists for an on-line and real-time technique to authenticate an association between a registering customer and a demand deposit account which mitigates occurrence of both incorrect entry of RTN/DDA information and fraud.
  • Some on-line payment services access more than one commercial database in the registration process in attempting to locate information used to authenticate a registering customer's identity (not to authenticate an association between a customer and a deposit account). Often an on-line service provider must access multiple commercial databases before useful information is found. These commercial databases charge for access, making this an expensive process.
  • Accordingly a need exists for a technique for registration for electronic commerce service which minimizes costs associated with utilizing information belonging to an entity other than an electronic commerce service provider.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • In order to facilitate a fuller understanding of the present invention, reference is now made to the appended drawings. These drawings should not be construed as limiting the present invention, but are intended to be exemplary only.
  • FIG. 1 depicts a computing system maintained by an electronic commerce service provider.
  • FIG. 2 depicts the processing to authenticate an association between a deposit account and a registering customer.
  • DETAILED DESCRIPTION OF AN EXEMPLARY EMBODIMENT
  • FIG. 1 shows an electronic commerce service system 100 maintained by an electronic commerce service provider (hereinafter, service provider). Included in system 100 is a processor 105 which is driven by instructions stored in memory 110. Processor 105 could be multiple processors working either in concert or independently to provide the functionality described herein. Likewise, memory 110 could be multiple memories. Processor 105 includes a rules engine 107 and a matching engine 108, which will be discussed below. Also shown is a communications interface 115 for communicating with registering customers and other entities. Though only one communications interface 115 is depicted, it should be understood that multiple communications interfaces could be included in system 100. Memory 110, in addition to storing the above described instructions, also stores a historical database 150 which stores information associated with registrations of each of multiple registering customers, data accumulated during provision of electronic commerce services, as well as other information used to determine which external databases (described below) to access during an on-line and real-time registration session. It will be appreciated that registration processing could be performed as a batch process. That is, not in real-time.
  • Also depicted in FIG. 1, though not necessarily a part of system 100, are multiple external databases 160A-160N. These external databases store information gathered by entities other than the service provider. Information stored in these external databases 160A-160N is utilized to authenticate an association between a registering customer and a deposit account.
  • These external databases 160A-160N belong to any one of, or any combination of, check printing services, check verification services, check guarantee services, and financial institutions. Examples of check printing services are Deluxe, Harland, and Clark American, though other check printing services' databases could also be accessed. Examples of check verification and/or guarantee services are Telecheck and Equifax Check Services, though other check verification and/or guarantee services' databases could also be accessed. A financial institution maintains deposit accounts on behalf of depositors, in addition to providing other financial services. A financial institution, obviously, has knowledge of associations between accounts that financial institution maintains and depositors (customers). A financial institution may have knowledge about associations between accounts and depositors for accounts that are maintained at other financial institutions. Information stored in external database 160A-160N is associated with deposit accounts. Check printing services retain information associated with each check order printed for an account holder. This information is typically retained so that a subsequent check order for the account holder can be printed without all account holder identifying and account identifying information being supplied a second time in order to print the second order. Thus, check printing services maintain information that authenticates an association between an account holder and an account.
  • It should be noted that one or more of the external databases 160A-160N, though belonging to an entity other than the service provider, could be hosted by the service provider. In such a case, a third party such as a check printing, verification, or guarantee service, would provide information to be stored to the service provider. The service provider would then access the service provider hosted external database(s) as necessary.
  • As shown in FIG. 2, a registering customer provides, during an on-line enrollment session, preferably via a World Wide Web interface 201, identifying information 105 such as one or more of name, drivers license number, and social security number to system 100. This information is received by communications interface 115. Any or all of this identifying information could be provided, in addition to other forms of identifying information. The registering customer also provides RTN/DDA information identifying a deposit account which they are authorizing the service provider to access. It should be noted that identifying information could be received from an entity other than a registering customer, such as a sponsor. Sponsors provide access to electronic commerce services on behalf of customers.
  • This received information is then processed by the rules engine 107 while the registering customer is still participating in the on-line enrollment session. The rules engine 107 first determines if historical database 150 contains information upon which a positive authentication between the registering customer and the customer's deposit account can be based. If so, the on-line registration session can be successfully completed without accessing commercial databases.
  • If the historical database 150 does not contain information which leads to a successful registration, then based upon logic derived from historical registration experience and other information contained in the historical database 150, the rules engine 107 determines which of external databases 160A-160N to access to authenticate an association between the registering customer and a deposit account. Criteria that can be used by the rules engine 107 in determining which external database to access includes the registering customer's financial institution's RTN (ABA) number. This information can be used because, based upon the historical information stored in the historical database 150, it is known that certain financial institutions utilize certain check printing services.
  • Other criteria that can be utilized to determine which of the external databases 160A-160N to access includes geographic criteria, such as the location of the registering customer and/or his or her financial institution. Yet another criteria is cost. That is, fees charged by entities maintaining external databases 160A-160N for accessing different ones of the external databases 160A-160N vary among the external databases. Still another criteria is a success rate of particular ones of the external databases 160A-160N in providing information useful in the registration process.
  • The rules engine 107 determines an order in which to access the external databases 160A-160N. Once the rules engine 107 determines the order in which the external databases 160A-160N should be accessed, the first determined external database is accessed in an attempt to locate information upon which to base an authentication determination.
  • If information upon which to base an authentication determination is not found in the first determined external database, the second determined external database is accessed. This process continues until information is found. It should be noted that if information for successful authentication information is not found in any database or other data store, the registering customer could be given the opportunity, on-line and in-session, to resubmit account identifying information, in view of the chance that the registering customer may have provided incorrect identifying information beforehand.
  • Once information is found in an external database, all or a portion of the information gathered via the web interface from the registering customer is used by the matching engine 108 in authenticating the RTN/DDA information received from the registering customer. That is, the matching engine 108 compares the RTN/DDA information and the identity information received from the registering customer with data stored in the external database. If the received data matches that supplied by the registering customer, the association is successfully authenticated.
  • Upon successful authentication, the registering customer is informed, via the on-line registration session, that registration is successful. The registering customer becomes a registered customer. The service provider can immediately and in-session provide services to the registered customer with confidence that an authentic association between the registered customer and a deposit account identified by that customer is in fact authentic.
  • In the event that on-line authentication of customer supplied information is unsuccessful, the registering customer would be required to complete the registration process by traditional techniques. This could include, for instance, requiring the registering customer to supply a voided check to the service provider, as well as any other known registration technique.
  • In a variation of the above-described process, instead of accessing the external databases 160A-160N in a determined order to determine if each database includes information which can be used in the authentication process, each of external databases 160A-160N are accessed, in the same determined order as above, and an authentication attempt is made against data stored in each external database. Thus, the first determined external database is accessed, and based upon data stored in that database an authentication attempt is made. If that authentication attempt is unsuccessful, the second determined external database is accessed and another authentication attempt is made. This process continues until a successful authentication is made, or until each database has been accessed. As above, if on-line authentication is unsuccessful, the registering customer would have to complete the registration process in an off-line fashion. In another variation, external databases 160A-160N could be accessed in a random order.
  • In yet another variation of the above-described process, an entity to whom an external database belongs might not offer direct access to the information stored in the database. In such a case, the service provider transmits at least a portion of the received identifying information as well as the RTN/DDA information to the entity to whom the external database belongs. That entity then compares this received information with information contained in the database.
  • That entity then returns a match key to the service provider. The match key could be one of four types: Account Found-Full Match, Account Found-No Match, Account Not Found, and Account Found-Possible Match. If the match key is of the Account Found-Full Match type, the authentication is successful. If the match key is of either the Account Found-No Match or Account Not Found types, the authentication is not successful and conventional, off-line, authentication techniques could be utilized. If the match key is of the Account Found-Possible Match type, further on-line activity can be performed to complete the authentication. This further activity could include the service provider providing further received identifying information to the entity to whom the database belongs, and could include the service provider querying the registering customer, via the still active on-line session, for additional identifying information, which would then be transmitted to the entity to whom the database belongs for further processing. It will be appreciated that the returned Match Key could be processed with other information to make the determination that authentication is successful or not. This other information could belong to the entity receiving the Match Key, or another entity. Also, instead of being processed with other information, a returned Match Key could be just one factor considered when making a determination as to a successful or unsuccessful authentication.
  • It should be noted that the inventive technique of on-line authentication of RTN/DDA information could be performed by the service provider on behalf of an entity other than the service provider. This authentication process could be performed in real-time, via perhaps a Web-based interface or a direct connection between another entity and the service provider, or could be performed as an asynchronous (e.g. batch file based or messaging-based) process for another entity. Further, it will be appreciated that the account authentication technique disclosed herein can be performed in a batch mode,
  • The present invention is not to be limited in scope by the specific embodiments described herein. Indeed, various modifications of the present invention in addition to those described herein, will be apparent to those of skill in the art from the foregoing description and accompanying drawings. Thus, such modifications are intended to fall within the scope of the appended claims.

Claims (28)

1. A method comprising:
receiving identity information and routing and transit number or account number (RTN/DDA) information, wherein at least a portion of identity information identifies an account holder and at least a portion of the RTN/DDA information identifies a deposit account;
selecting at least one database of a plurality of databases to authenticate an association between the deposit account and the account holder, wherein the selection is based on at least one criterion;
accessing the at least one database of the plurality of databases; and
authenticating an association between the deposit account and the account holder using the received identity information and RTN/DDA information and the at least one database.
2. The method of claim 1, wherein the identity information includes identifying information selected from the group consisting of a name, drivers license number, and social security number.
3. The method of claim 1, wherein the at least one criterion is selected from a group consisting of (i) the RTN portion of the RTN/DDA information, (ii) a geographic location associated with the account holder, (iii) a geographic location associated with the financial institution associated with the first deposit account, (iv) a cost associated with accessing the at least one database, (v) a success rate associated with using the at least one database to authenticate associations between deposit accounts and account holders and (vi) historical information stored in a historical database.
4. The method of claim 1, wherein one or more of the plurality of databases is an external database.
5. The method of claim 1 wherein authenticating an association between the deposit account and the account holder is conducted in real time during an on-line enrollment session.
6. The method of claim 1, further comprising:
prior to selecting at least one database of a plurality of databases to authenticate an association between the deposit account and the account holder, processing the identifying information to determine whether a historical database contains historical information upon which a positive authentication between the deposit account and the account holder may be based; and
wherein the at least one database of the plurality of databases is selected to authenticate an association between the deposit account and the account holder if the historical database cannot be used to positively authenticate the association between the first deposit account and the account holder.
7. The method of claim 6, wherein the historical database is an internal database.
8. The method of claim 1, further comprising:
subsequent to authenticating an association between the deposit account and the account holder, registering the account holder to use a service.
9. The method of claim 8, wherein registering the account holder includes informing the account holder that registration has been successful.
10. The method of claim 1, further comprising, prior to accessing the at least one database, determining an order to access more than one of the plurality of databases to authenticate an association between the deposit account and the account holder.
11. The method of claim 10, further comprising:
processing the received identity information and RTN/DDA information to identify a first database and a second database of the plurality of databases; and
wherein determining an order to access more than one of the plurality of databases to authenticate an association between the deposit account and the account holder includes determining an order in which to access the first database and the second database.
12. The method of claim 1, wherein the order identifies the first database as the first to be accessed.
13. The method of claim 12, further comprising:
upon failing to authenticate the association between the deposit account and the account holder using the first database, accessing the second database using the received identity information and RTN/DDA information for authentication.
14. A system comprising:
at least one communication interface, wherein the at least one communication interface receives at least one of identity information and routing and transit number or account number (RTN/DDA) information, wherein at least a portion of identity information identifies an account holder and at least a portion of the RTN/DDA information identifies a deposit account; and
a processor, in communication with the at least one communication interface, wherein the processor contains programmed logic to execute software instructions for:
receiving the at least one identity information and RTN/DDA information from the communication interface,
selecting at least one database of a plurality of databases to authenticate an association between the deposit account and the account holder, wherein the selection is based on at least one criterion;
accessing the at least one database of the plurality of databases; and
authenticating an association between the deposit account and the account holder using the received identity information and RTN/DDA information and the at least one database.
15. The system of claim 14, wherein the identity information includes identifying information selected from the group consisting of a name, drivers license number, and social security number.
16. The system of claim 14, wherein the at least one criterion is selected from a group consisting of (i) the RTN portion of the RTN/DDA information, (ii) a geographic location associated with the account holder, (iii) a geographic location associated with the financial institution associated with the first deposit account, (iv) a cost associated with accessing the at least one database, (v) a success rate associated with using the at least one database to authenticate associations between deposit accounts and account holders and (vi) historical information stored in a historical database.
17. The system of claim 14, wherein one or more of the plurality of databases is an external database.
18. The system of claim 14, wherein the external database belongs to one or more entities selected from the group consisting of check printing services, check verification services, check guarantee services, and financial institutions.
19. The system of claim 14, wherein the processor contains programmed logic to execute software instructions for authenticating an association between the deposit account and the account holder in real time during an on-line enrollment session.
20. The system of claim 14, wherein the processor contains programmed logic to execute software instructions for:
prior to selecting at least one database of a plurality of databases to authenticate an association between the deposit account and the account holders processing the identifying information to determine whether a historical database contains historical information upon which a positive authentication between the deposit account and the account holder may be based; and
wherein the at least one database of the plurality of databases is selected to authenticate an association between the deposit account and the account holder if the historical database cannot be used to positively authenticate the association between the first deposit account and the account holder.
21. The system of claim 20, wherein the historical database is an internal database.
22. The system of claim 14, wherein the processor contains programmed logic to execute software instructions for:
subsequent to authenticating an association between the deposit account and the account holder, registering the account holder to use a service.
23. The system of claim 22, wherein the software instructions for registering the account holder include software instruction for informing the account holder that registration has been successful.
24. The system of claim 14, wherein the processor contains programmed logic to execute software instructions for:
prior to accessing the at least one database, determining an order to access more than one of the plurality of databases to authenticate an association between the deposit account and the account holder.
25. The system of claim 24, wherein the processor contains programmed logic to execute software instructions for:
processing the received identity information and RTN/DDA information to identify a first database and a second database of the plurality of databases; and
wherein determining an order to access more than one of the plurality of databases to authenticate an association between the deposit account and the account holder includes determining an order in which to access the first database and the second database.
26. The system of claim 25, wherein the order identifies the first database as the first to be accessed.
27. The system of claim 26, wherein the processor contains programmed logic to execute software instructions for:
upon failing to authenticate the association between the deposit account and the account holder using the first database, accessing the second database using the received identity information and RTN/DDA information for authentication.
28. A system comprising:
means for receiving identity information and routing and transit number or account number (RTN/DDA) information, wherein at least a portion of identity information identifies an account holder and at least a portion of the RTN/DDA information identifies a deposit account;
means for selecting at least one database of a plurality of databases to authenticate an association between the deposit account and the account holder, wherein the selection is based on at least one criterion;
means for accessing the at least one database of the plurality of databases; and
means for authenticating an association between the deposit account and the account holder using the received identity information and RTN/DDA information and the at least one database.
US11/612,254 2002-07-29 2006-12-18 Systems and Methods of Rules-Based Database Access For Account Authentication Abandoned US20070094151A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US11/612,254 US20070094151A1 (en) 2002-07-29 2006-12-18 Systems and Methods of Rules-Based Database Access For Account Authentication

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US10/206,239 US7177846B2 (en) 2002-07-29 2002-07-29 Technique for account authentication
US11/612,254 US20070094151A1 (en) 2002-07-29 2006-12-18 Systems and Methods of Rules-Based Database Access For Account Authentication

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US10/206,239 Continuation US7177846B2 (en) 2002-07-29 2002-07-29 Technique for account authentication

Publications (1)

Publication Number Publication Date
US20070094151A1 true US20070094151A1 (en) 2007-04-26

Family

ID=30770242

Family Applications (2)

Application Number Title Priority Date Filing Date
US10/206,239 Expired - Fee Related US7177846B2 (en) 2002-07-29 2002-07-29 Technique for account authentication
US11/612,254 Abandoned US20070094151A1 (en) 2002-07-29 2006-12-18 Systems and Methods of Rules-Based Database Access For Account Authentication

Family Applications Before (1)

Application Number Title Priority Date Filing Date
US10/206,239 Expired - Fee Related US7177846B2 (en) 2002-07-29 2002-07-29 Technique for account authentication

Country Status (1)

Country Link
US (2) US7177846B2 (en)

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7979348B2 (en) 2002-04-23 2011-07-12 Clearing House Payments Co Llc Payment identification code and payment system using the same
CN103049851A (en) * 2012-12-27 2013-04-17 中国建设银行股份有限公司 Transaction data-based anti-fraud monitoring method and device
US8725607B2 (en) 2004-01-30 2014-05-13 The Clearing House Payments Company LLC Electronic payment clearing and check image exchange systems and methods
WO2020228530A1 (en) * 2019-05-16 2020-11-19 中国银联股份有限公司 Repeated transaction risk monitoring method and device, and computer readable storage medium
US11042882B2 (en) 2015-07-01 2021-06-22 The Clearing House Payments Company, L.L.C. Real-time payment system, method, apparatus, and computer program
US11295308B1 (en) 2014-10-29 2022-04-05 The Clearing House Payments Company, L.L.C. Secure payment processing
US11436577B2 (en) 2018-05-03 2022-09-06 The Clearing House Payments Company L.L.C. Bill pay service with federated directory model support
US11694168B2 (en) 2015-07-01 2023-07-04 The Clearing House Payments Company L.L.C. Real-time payment system, method, apparatus, and computer program

Families Citing this family (64)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7930340B2 (en) * 1995-11-13 2011-04-19 Lakshmi Arunachalam Network transaction portal to control multi-service provider transactions
US8271339B2 (en) * 1995-11-13 2012-09-18 Lakshmi Arunachalam Method and apparatus for enabling real-time bi-directional transactions on a network
US8037158B2 (en) * 1995-11-13 2011-10-11 Lakshmi Arunachalam Multimedia transactional services
US8706630B2 (en) 1999-08-19 2014-04-22 E2Interactive, Inc. System and method for securely authorizing and distributing stored-value card data
US7383227B2 (en) * 2002-05-14 2008-06-03 Early Warning Services, Llc Database for check risk decisions populated with check activity data from banks of first deposit
US20040138975A1 (en) * 2002-12-17 2004-07-15 Lisa Engel System and method for preventing fraud in check orders
US20040230448A1 (en) * 2003-02-14 2004-11-18 William Schaich System for managing and reporting financial account activity
US20040215790A1 (en) * 2003-04-24 2004-10-28 Miller Robert A. Information network access
US20050049950A1 (en) * 2003-09-03 2005-03-03 Allcard Financial Services, Inc. Method for depositing funds to a stored value card
US8655309B2 (en) 2003-11-14 2014-02-18 E2Interactive, Inc. Systems and methods for electronic device point-of-sale activation
US10346620B2 (en) 2004-02-06 2019-07-09 Early Warning Service, LLC Systems and methods for authentication of access based on multi-data source information
US20050177542A1 (en) * 2004-02-06 2005-08-11 Glen Sgambati Account-owner verification database
US7337953B2 (en) * 2004-02-06 2008-03-04 Early Warning Services, Llc. Negotiable instrument authentication systems and methods
US20050289037A1 (en) * 2004-06-15 2005-12-29 Smith Joseph B Financial asset product and method for implementing same
US7566002B2 (en) * 2005-01-06 2009-07-28 Early Warning Services, Llc Identity verification systems and methods
US20060282270A1 (en) * 2005-06-09 2006-12-14 First Data Corporation Identity verification noise filter systems and methods
US8290836B2 (en) * 2005-06-22 2012-10-16 Early Warning Services, Llc Identification and risk evaluation
US8109435B2 (en) 2005-07-14 2012-02-07 Early Warning Services, Llc Identity verification switch
WO2007028048A2 (en) * 2005-09-02 2007-03-08 Fair Isaac Corporation Systems and methods for detecting fraud
US20070233614A1 (en) 2006-03-30 2007-10-04 Early Warning Services, Llc Management of biometric information
US8121945B2 (en) 2006-07-06 2012-02-21 Firethorn Mobile, Inc. Methods and systems for payment method selection by a payee in a mobile environment
US8145568B2 (en) * 2006-07-06 2012-03-27 Firethorn Mobile, Inc. Methods and systems for indicating a payment in a mobile environment
US8489067B2 (en) * 2006-07-06 2013-07-16 Qualcomm Incorporated Methods and systems for distribution of a mobile wallet for a mobile device
US20080010204A1 (en) * 2006-07-06 2008-01-10 Firethorn Holdings, Llc Methods and Systems For Making a Payment Via a Paper Check in a Mobile Environment
US8510220B2 (en) * 2006-07-06 2013-08-13 Qualcomm Incorporated Methods and systems for viewing aggregated payment obligations in a mobile environment
US20080010191A1 (en) * 2006-07-06 2008-01-10 Firethorn Holdings, Llc Methods and Systems For Providing a Payment in a Mobile Environment
US8467766B2 (en) * 2006-07-06 2013-06-18 Qualcomm Incorporated Methods and systems for managing payment sources in a mobile environment
US8160959B2 (en) 2006-07-06 2012-04-17 Firethorn Mobile, Inc. Methods and systems for payment transactions in a mobile environment
US9911114B2 (en) * 2006-07-06 2018-03-06 Qualcomm Incorporated Methods and systems for making a payment via a stored value card in a mobile environment
US20090006230A1 (en) * 2007-06-27 2009-01-01 Checkfree Corporation Identity Risk Scoring
US7958050B2 (en) * 2007-07-02 2011-06-07 Early Warning Services, Llc Payment account monitoring system and method
WO2009026460A1 (en) 2007-08-23 2009-02-26 Giftango Corporation Systems and methods for electronic delivery of stored value
US9105019B1 (en) * 2008-04-17 2015-08-11 Intuit Inc. Method and system for depositing funds at a point of sale terminal
US8312033B1 (en) 2008-06-26 2012-11-13 Experian Marketing Solutions, Inc. Systems and methods for providing an integrated identifier
CN102187353A (en) * 2008-09-05 2011-09-14 吉弗坦戈公司 Systems and methods for authentication of a virtual stored value card
US20100076833A1 (en) * 2008-09-19 2010-03-25 Giftango Corporation Systems and methods for managing and using a virtual card
WO2010036737A2 (en) * 2008-09-26 2010-04-01 Giftango Corporation System and methods for managing a virtual card based on geographical information
US20110137740A1 (en) 2009-12-04 2011-06-09 Ashmit Bhattacharya Processing value-ascertainable items
US11928696B2 (en) 2009-12-16 2024-03-12 E2Interactive, Inc. Systems and methods for generating a virtual value item for a promotional campaign
US20110184840A1 (en) * 2010-01-27 2011-07-28 Ebay Inc. Systems and methods for facilitating account verification over a network
US9132204B2 (en) 2010-03-31 2015-09-15 Enviroscent, Inc. Methods, compositions and articles for olfactory-active substances
US10068287B2 (en) 2010-06-11 2018-09-04 David A. Nelsen Systems and methods to manage and control use of a virtual card
US9031869B2 (en) 2010-10-13 2015-05-12 Gift Card Impressions, LLC Method and system for generating a teaser video associated with a personalized gift
US9483786B2 (en) 2011-10-13 2016-11-01 Gift Card Impressions, LLC Gift card ordering system and method
US8498934B2 (en) * 2010-10-21 2013-07-30 Bml Productions, Inc. Multi-account payment consolidation system
US9665854B1 (en) 2011-06-16 2017-05-30 Consumerinfo.Com, Inc. Authentication alerts
US10417677B2 (en) 2012-01-30 2019-09-17 Gift Card Impressions, LLC Group video generating system
CN104769626A (en) 2012-09-04 2015-07-08 Linq3科技公司 Systems and methods for integrated game play through the use of barcodes on smart phones and hand held devices
US10229561B2 (en) 2012-09-04 2019-03-12 Linq3 Technologies Llc Processing of a user device game-playing transaction based on location
US10943432B2 (en) 2012-09-04 2021-03-09 E2Interactive, Inc. Processing of a game-playing transaction based on location
US11219288B2 (en) 2013-02-15 2022-01-11 E2Interactive, Inc. Gift card box with slanted tray and slit
US9565911B2 (en) 2013-02-15 2017-02-14 Gift Card Impressions, LLC Gift card presentation devices
US10664936B2 (en) 2013-03-15 2020-05-26 Csidentity Corporation Authentication systems and methods for on-demand products
US10115268B2 (en) 2013-03-15 2018-10-30 Linq3 Technologies Llc Systems and methods for integrated game play at payment-enabled terminals
US9633322B1 (en) 2013-03-15 2017-04-25 Consumerinfo.Com, Inc. Adjustment of knowledge-based authentication
US10217107B2 (en) 2013-05-02 2019-02-26 Gift Card Impressions, LLC Stored value card kiosk system and method
US9721147B1 (en) 2013-05-23 2017-08-01 Consumerinfo.Com, Inc. Digital identity
US10373240B1 (en) 2014-04-25 2019-08-06 Csidentity Corporation Systems, methods and computer-program products for eligibility verification
US10262346B2 (en) 2014-04-30 2019-04-16 Gift Card Impressions, Inc. System and method for a merchant onsite personalization gifting platform
US9149552B1 (en) 2014-09-29 2015-10-06 Enviroscent, Inc. Coating providing modulated release of volatile compositions
US9875468B2 (en) 2014-11-26 2018-01-23 Buy It Mobility Networks Inc. Intelligent authentication process
US10596290B2 (en) 2015-06-09 2020-03-24 Enviroscent, Inc. Formed three-dimensional matrix and associated coating providing modulated release of volatile compositions
US10954049B2 (en) 2017-12-12 2021-03-23 E2Interactive, Inc. Viscous liquid vessel for gifting
US10911234B2 (en) 2018-06-22 2021-02-02 Experian Information Solutions, Inc. System and method for a token gateway environment

Citations (30)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4823264A (en) * 1986-05-27 1989-04-18 Deming Gilbert R Electronic funds transfer system
US5025373A (en) * 1988-06-30 1991-06-18 Jml Communications, Inc. Portable personal-banking system
US5220501A (en) * 1989-12-08 1993-06-15 Online Resources, Ltd. Method and system for remote delivery of retail banking services
US5283829A (en) * 1992-10-01 1994-02-01 Bell Communications Research, Inc. System and method for paying bills electronically
US5326959A (en) * 1992-08-04 1994-07-05 Perazza Justin J Automated customer initiated entry remittance processing system
US5336870A (en) * 1992-05-26 1994-08-09 Hughes Thomas S System for remote purchase payment transactions and remote bill payments
US5383113A (en) * 1991-07-25 1995-01-17 Checkfree Corporation System and method for electronically providing customer services including payment of bills, financial analysis and loans
US5420405A (en) * 1993-02-26 1995-05-30 Chasek; Norman E. Secure, automated transaction system that supports an electronic currency operating in mixed debit & credit modes
US5465206A (en) * 1993-11-01 1995-11-07 Visa International Electronic bill pay system
US5504677A (en) * 1992-10-15 1996-04-02 Pollin; Robert E. Automated payment system
US5677955A (en) * 1995-04-07 1997-10-14 Financial Services Technology Consortium Electronic funds transfer instruments
US5699528A (en) * 1995-10-31 1997-12-16 Mastercard International, Inc. System and method for bill delivery and payment over a communications network
US5710889A (en) * 1995-02-22 1998-01-20 Citibank, N.A. Interface device for electronically integrating global financial services
US5794221A (en) * 1995-07-07 1998-08-11 Egendorf; Andrew Internet billing method
US5884288A (en) * 1996-07-01 1999-03-16 Sun Microsystems, Inc. Method and system for electronic bill payment
US5920847A (en) * 1993-11-01 1999-07-06 Visa International Service Association Electronic bill pay system
US5920848A (en) * 1997-02-12 1999-07-06 Citibank, N.A. Method and system for using intelligent agents for financial transactions, services, accounting, and advice
US5966698A (en) * 1992-10-15 1999-10-12 Pollin; Robert E. Automated payment system and method
US5974146A (en) * 1997-07-30 1999-10-26 Huntington Bancshares Incorporated Real time bank-centric universal payment system
US5978780A (en) * 1997-11-21 1999-11-02 Craig Michael Watson Integrated bill consolidation, payment aggregation, and settlement system
US6029150A (en) * 1996-10-04 2000-02-22 Certco, Llc Payment and transactions in electronic commerce system
US6098053A (en) * 1998-01-28 2000-08-01 Citibank, N.A. System and method for performing an electronic financial transaction
US6311170B1 (en) * 1996-12-04 2001-10-30 Mark C. Embrey Method and apparatus for making payments and delivering payment information
US20020004772A1 (en) * 2000-07-10 2002-01-10 Templeton James E. System and method for verifying a financial instrument
US20020040346A1 (en) * 2000-09-27 2002-04-04 Kwan Khai Hee Computer system and method for on-line generating a password protected and barcode prepaid instrument of entitlement and activating said instrument on presentation over a computer network
US20030093367A1 (en) * 2001-11-15 2003-05-15 First Data Corporation Online incremental payment method
US20030200180A1 (en) * 2000-05-08 2003-10-23 Frank Phelan Money card system, method and apparatus
US6647376B1 (en) * 1998-10-09 2003-11-11 Henry C. Farrar System and method for point-of-sale check authorization
US20040199466A1 (en) * 2000-05-03 2004-10-07 Ecardworld. Com, Llc, A Massachusetts Limited Liability Corporation Financial account management
US6820802B2 (en) * 2001-02-27 2004-11-23 American Express Travel Related Services Company, Inc. Online card activation system and method

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5465829A (en) * 1994-01-31 1995-11-14 Sudenga Industries, Inc. Pallet with hopper and auguer and method for distributing particular material
US20010037295A1 (en) 2000-01-31 2001-11-01 Olsen Karl R. Push model internet bill presentment and payment system and method

Patent Citations (35)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4823264A (en) * 1986-05-27 1989-04-18 Deming Gilbert R Electronic funds transfer system
US5025373A (en) * 1988-06-30 1991-06-18 Jml Communications, Inc. Portable personal-banking system
US5220501A (en) * 1989-12-08 1993-06-15 Online Resources, Ltd. Method and system for remote delivery of retail banking services
US5383113A (en) * 1991-07-25 1995-01-17 Checkfree Corporation System and method for electronically providing customer services including payment of bills, financial analysis and loans
US5873072A (en) * 1991-07-25 1999-02-16 Checkfree Corporation System and method for electronically providing customer services including payment of bills, financial analysis and loans
US5336870A (en) * 1992-05-26 1994-08-09 Hughes Thomas S System for remote purchase payment transactions and remote bill payments
US5326959A (en) * 1992-08-04 1994-07-05 Perazza Justin J Automated customer initiated entry remittance processing system
US5283829A (en) * 1992-10-01 1994-02-01 Bell Communications Research, Inc. System and method for paying bills electronically
US5727249A (en) * 1992-10-15 1998-03-10 Pollin; Robert E. Automated payment system and method
US5504677A (en) * 1992-10-15 1996-04-02 Pollin; Robert E. Automated payment system
US5966698A (en) * 1992-10-15 1999-10-12 Pollin; Robert E. Automated payment system and method
US5420405A (en) * 1993-02-26 1995-05-30 Chasek; Norman E. Secure, automated transaction system that supports an electronic currency operating in mixed debit & credit modes
US5465206A (en) * 1993-11-01 1995-11-07 Visa International Electronic bill pay system
US5465206B1 (en) * 1993-11-01 1998-04-21 Visa Int Service Ass Electronic bill pay system
US5920847A (en) * 1993-11-01 1999-07-06 Visa International Service Association Electronic bill pay system
US6032133A (en) * 1993-11-01 2000-02-29 Visainternational Service Association Electronic bill pay system
US5710889A (en) * 1995-02-22 1998-01-20 Citibank, N.A. Interface device for electronically integrating global financial services
US5677955A (en) * 1995-04-07 1997-10-14 Financial Services Technology Consortium Electronic funds transfer instruments
US5794221A (en) * 1995-07-07 1998-08-11 Egendorf; Andrew Internet billing method
US6188994B1 (en) * 1995-07-07 2001-02-13 Netcraft Corporation Internet billing method
US5699528A (en) * 1995-10-31 1997-12-16 Mastercard International, Inc. System and method for bill delivery and payment over a communications network
US5884288A (en) * 1996-07-01 1999-03-16 Sun Microsystems, Inc. Method and system for electronic bill payment
US6029150A (en) * 1996-10-04 2000-02-22 Certco, Llc Payment and transactions in electronic commerce system
US6311170B1 (en) * 1996-12-04 2001-10-30 Mark C. Embrey Method and apparatus for making payments and delivering payment information
US5920848A (en) * 1997-02-12 1999-07-06 Citibank, N.A. Method and system for using intelligent agents for financial transactions, services, accounting, and advice
US5974146A (en) * 1997-07-30 1999-10-26 Huntington Bancshares Incorporated Real time bank-centric universal payment system
US5978780A (en) * 1997-11-21 1999-11-02 Craig Michael Watson Integrated bill consolidation, payment aggregation, and settlement system
US6098053A (en) * 1998-01-28 2000-08-01 Citibank, N.A. System and method for performing an electronic financial transaction
US6647376B1 (en) * 1998-10-09 2003-11-11 Henry C. Farrar System and method for point-of-sale check authorization
US20040199466A1 (en) * 2000-05-03 2004-10-07 Ecardworld. Com, Llc, A Massachusetts Limited Liability Corporation Financial account management
US20030200180A1 (en) * 2000-05-08 2003-10-23 Frank Phelan Money card system, method and apparatus
US20020004772A1 (en) * 2000-07-10 2002-01-10 Templeton James E. System and method for verifying a financial instrument
US20020040346A1 (en) * 2000-09-27 2002-04-04 Kwan Khai Hee Computer system and method for on-line generating a password protected and barcode prepaid instrument of entitlement and activating said instrument on presentation over a computer network
US6820802B2 (en) * 2001-02-27 2004-11-23 American Express Travel Related Services Company, Inc. Online card activation system and method
US20030093367A1 (en) * 2001-11-15 2003-05-15 First Data Corporation Online incremental payment method

Cited By (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10387879B2 (en) 2002-04-23 2019-08-20 The Clearing Housse Payments Company L.L.C. Payment identification code and payment system using the same
US7979348B2 (en) 2002-04-23 2011-07-12 Clearing House Payments Co Llc Payment identification code and payment system using the same
US10643190B2 (en) 2004-01-30 2020-05-05 The Clearing House Payments Company L.L.C. Electronic payment clearing and check image exchange systems and methods
US9799011B2 (en) 2004-01-30 2017-10-24 The Clearing House Payments Company L.L.C. Electronic payment clearing and check image exchange systems and methods
US8725607B2 (en) 2004-01-30 2014-05-13 The Clearing House Payments Company LLC Electronic payment clearing and check image exchange systems and methods
US10636018B2 (en) 2004-01-30 2020-04-28 The Clearing House Payments Company L.L.C. Electronic payment clearing and check image exchange systems and methods
US10685337B2 (en) 2004-01-30 2020-06-16 The Clearing House Payments Company L.L.C. Electronic payment clearing and check image exchange systems and methods
US11301824B2 (en) 2004-01-30 2022-04-12 The Clearing House Payments Company LLC Electronic payment clearing and check image exchange systems and methods
CN103049851A (en) * 2012-12-27 2013-04-17 中国建设银行股份有限公司 Transaction data-based anti-fraud monitoring method and device
US11816666B2 (en) 2014-10-29 2023-11-14 The Clearing House Payments Company L.L.C. Secure payment processing
US11295308B1 (en) 2014-10-29 2022-04-05 The Clearing House Payments Company, L.L.C. Secure payment processing
US11694168B2 (en) 2015-07-01 2023-07-04 The Clearing House Payments Company L.L.C. Real-time payment system, method, apparatus, and computer program
US11042882B2 (en) 2015-07-01 2021-06-22 The Clearing House Payments Company, L.L.C. Real-time payment system, method, apparatus, and computer program
US11436577B2 (en) 2018-05-03 2022-09-06 The Clearing House Payments Company L.L.C. Bill pay service with federated directory model support
US11829967B2 (en) 2018-05-03 2023-11-28 The Clearing House Payments Company L.L.C. Bill pay service with federated directory model support
WO2020228530A1 (en) * 2019-05-16 2020-11-19 中国银联股份有限公司 Repeated transaction risk monitoring method and device, and computer readable storage medium

Also Published As

Publication number Publication date
US7177846B2 (en) 2007-02-13
US20040019568A1 (en) 2004-01-29

Similar Documents

Publication Publication Date Title
US7177846B2 (en) Technique for account authentication
US10558960B2 (en) Cash payment for remote transactions
US5884274A (en) System and method for generating and executing insurance policies for foreign exchange losses
US8515871B2 (en) Authorizing use of a financial instrument
US6339766B1 (en) Electronic payment system employing limited-use account number
US7395241B1 (en) Consumer-directed financial transfers using automated clearinghouse networks
US7599888B2 (en) Electronic confirmation to debit or credit an account
US7089208B1 (en) System and method for electronically exchanging value among distributed users
US8266059B2 (en) Methods and apparatus for preventing fraud in payment processing transactions
US7392942B2 (en) Systems and methods for electronic transaction risk processing
US20070284432A1 (en) Method and system for flexible purchases using only fingerprints at the time and location of purchase
US20030233317A1 (en) Methods and systems for transferring funds
US20040089711A1 (en) Payment validation network
US20030061172A1 (en) System and method for biometric authorization for financial transactions
US20060294005A1 (en) Universal e-money brokerage service and method
US20050234817A1 (en) Methods and systems for private label transaction processing
US20050097049A1 (en) Methods for verifying cardholder authenticity and for creating billing address database
US7658322B2 (en) Enhanced pre-allocated check negotiability systems and methods
US20070299775A1 (en) Systems and methods for associating a second source of funds with an electronic check transaction
US8543495B1 (en) Online electronic transaction and funds transfer method and system
JP2003058714A (en) Transfer processing deciding system
CA2758331C (en) System and method for electronically exchanging value among distributed users
WO2000046724A1 (en) Method for authorizing access to a secure online financial transaction system

Legal Events

Date Code Title Description
STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION