Verification of a financial instrument allowing rules-based pre-acceptance use of the financial instrument

• US 8,332,317 B1
• Filed: 10/31/2002
• Issued: 12/11/2012
• Est. Priority Date: 10/31/2002
• Status: Active Grant

• Current Assignee: Checkfree Services Corporation (Fiserv Incorporated)
• Original Assignee: Checkfree Corporation (Fiserv Incorporated)
• Inventors: McCoy, Randal A., Magers, James G.
• Primary Examiner(s): Kazimi, Hani M
• Assistant Examiner(s): ONYEZIA, CHUKS N
• Application Number:
  US10/284,448
• Time in Patent Office: 3,694 Days
• Field of Search: 705/36, 705/43, 705/44, 705/39, 705/40
• US Class Current: 705/40
• CPC Class Codes: G06Q 20/10 specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
• CPC Class Codes: G06Q 40/02 Banking, e.g. interest calculation or account maintenance credit or loans G06Q40/03

Abstract

A method of verifying authority of a customer to use a financial instrument, includes initiating one or more transactions using a financial instrument identified by a customer. One or more attributes of the initiated one or more transactions are stored. A determination is made as to whether or not a further financial transaction using the identified financial instrument, requested by the customer prior to acceptance of the use of the financial instrument, complies with pre-acceptance transaction rules. The further transaction is initiated only if it is determined to comply with the pre-acceptance transaction rules. One or more proffered attributes are received, typically from the customer. The received proffered attributes are compared to the stored attributes. Use of the financial instrument by the customer is then accepted if the received proffered attributes correspond to the stored attributes.

Claims

1. A method, comprising:

receiving, by a service provider system comprising one or more computers, identification of a payment account to be used in fulfilling payment requests submitted by a subscriber to a service provider;

responsive to receiving the identification of the payment account, confirming, by the service provider system, a legitimate association of the payment account with the subscriber;

upon confirming the legitimate association of the payment account with the subscriber, storing, by the service provider system, an indication that the payment account is confirmed as a confirmed account for use in funding future payment requests from the subscriber; and

prior to storing the indication that the payment account is confirmed as a confirmed account;

receiving, by the service provider system, a payment request on behalf of the subscriber specifying the payment account as the source of funds, the payment account being unconfirmed prior to storing the indication that the payment account is confirmed,

determining, by the service provider system, that the unconfirmed payment account is not indicated as a confirmed account,

in response to determining that the unconfirmed payment account is not indicated as a confirmed account, determining, by the service provider system, that the payment request complies with at least one pre-acceptance transaction rule, wherein each of the at least one pre-acceptance transaction rule specifies at least one respective criterion for allowing payment request processing utilizing the unconfirmed payment account prior to storing the indication that the unconfirmed payment account is confirmed for use in funding future payment requests from the subscriber, and

directing, by the service provider system, payment from the unconfirmed account in accordance with the payment request after determining that the payment request complies with the at least one pre-acceptance transaction rule.

2. The method of claim 1, wherein the payment request includes a transaction date and a transaction amount;

wherein the at least one pre-acceptance transaction rule includes at least one of;

a pre-confirmation date indicating a date beyond which the payment request cannot be processed, and a pre-confirmation amount indicating an amount which, if exceeded, the payment request cannot be processed; and

wherein determining that the payment request complies with at least one pre-acceptance transaction rule includes determining that the payment request complies with at least one pre-acceptance transaction rule when the transaction date is earlier than the pre-confirmation date or when the transaction amount does not exceed the pre-confirmation amount.

3. The method of claim 1, wherein the payment account is one of (i) a checking account, (ii) a savings account, (iii) a money market account, or (iv) a line of credit.

4. The method of claim 1, further comprising:

storing a plurality of different pre-acceptance transaction rules; and

prior to determining that the payment request complies with the at least one pre-acceptance transaction rule, selecting the at least one pre-acceptance transaction rule from the stored plurality of different pre-acceptance transaction rules.

5. The method of claim 4, wherein the at least one pre-acceptance transaction rule is selected based on the subscriber or a sponsor of the subscriber.

6. The method of claim 1, wherein the payment account is with a financial institution separate from the service provider.

7. The method of claim 1, wherein receiving the identification of the payment account occurs over a first network and confirming the legitimate association of the payment account with the subscriber occurs over a second network.

16. The method of claim 1, wherein the payment request is a first payment request, and further comprising:

prior to completing the confirmation of the legitimate association of the payment account with the subscriber;

receiving, at the service provider, a second payment request on behalf of the subscriber specifying the payment account as the source of funds,

determining, at the service provider, that the second payment request does not comply with at least one pre-acceptance transaction rule, and

transmitting, from the service provider, a message to the subscriber informing the subscriber the second payment request is not valid.

17. The method of claim 16, further comprising:

after completing the confirmation of the legitimate association of the payment account with the subscriber;

receiving a third payment request, wherein the third payment request is a re-submission of the second payment request, and

directing payment in accordance with the third payment request.

20. The method of claim 1, wherein confirming the legitimate association of the payment account with the subscriber includes the service provider initiating at least one debit or credit transaction against the payment account and subsequently receiving transaction information from the subscriber, and wherein the transaction information includes or is associated with an attribute of the at least one debit or credit transaction.

21. The method of claim 20, wherein the service provider initiating at least one debit or credit transaction against the payment account includes initiating at least one debit transaction and at least one credit transaction against the payment account, wherein each debit or credit transaction has an amount, and wherein the sum of the amounts of the at least one credit transaction offsets the sum of the amounts of the at least one debit transaction.

22. The method of claim 20, wherein the service provider initiating at least one debit or credit transaction against the payment account includes initiating at least one debit or credit transaction against the payment account, wherein the number of the debit or credit transactions initiated is determined by generating at least one random number.

8. A system comprising:

a storage device, wherein the storage device includes at least one pre-acceptance transaction rule; and

a processor, in communication with the storage device, wherein the processor is configured to execute software instructions to;

receive, from a subscriber, identification of a payment account to be used in fulfilling payment requests submitted by a subscriber to a service provider;

responsive to receiving the identification of the payment account, confirm a legitimate association of the payment account with the subscriber;

upon confirming the legitimate association of the payment account with the subscriber, storing an indication that the payment account is confirmed as a confirmed account for use in funding future payment requests from the subscriber; and

prior to storing the indication that the payment account is confirmed as a confirmed account;

receive a payment request on behalf of the subscriber specifying the payment account as the source of funds, the payment account being unconfirmed prior to storing the indication that the payment account is confirmed,

determining, by the service provider system, that the unconfirmed payment account is not indicated as a confirmed account,

in response to determining that the unconfirmed payment account is not indicated as a confirmed account, determine that the payment request complies with the at least one pre-acceptance transaction rule, wherein each of the at least one pre-acceptance transaction rule specifies at least one respective criterion for allowing payment request processing utilizing the unconfirmed payment account prior to storing the indication that the unconfirmed payment account is confirmed for use in funding future payment requests from the subscriber, and

direct payment from the unconfirmed account in accordance with the payment request after determining that the payment request complies with the at least one pre-acceptance transaction rule.

9. The system of claim 8, wherein the payment request includes a transaction date and a transaction amount;

wherein the at least one pre-acceptance transaction rule includes at least one of;

a pre-confirmation date indicating a date beyond which the payment request cannot be processed, and a pre-confirmation amount indicating an amount which, if exceeded, the payment request cannot be processed; and

wherein determining that the payment request complies with at least one pre-acceptance transaction rule includes determining that the payment request complies with at least one pre-acceptance transaction rule when the transaction date is earlier than the pre-confirmation date or when the transaction amount does not exceed the pre-confirmation amount.

10. The system of claim 8, wherein the payment account is one of (i) a checking account, (ii) a savings account, (iii) a money market account, or (iv) a line of credit.

11. The system of claim 8, wherein the processor is configured to execute additional software instructions to:

store a plurality of different pre-acceptance transaction rules; and

prior to determining that the payment request complies with the at least one pre-acceptance transaction rule, select the at least one pre-acceptance transaction rule from the stored plurality of different pre-acceptance transaction rules.

12. The system of claim 11, wherein the at least one pre-acceptance transaction rule is selected based on the subscriber or a sponsor of the subscriber.

13. The system of claim 8, wherein the payment account is with a financial institution separate from the service provider.

14. The system of claim 8, wherein receiving the identification of the payment account occurs over a first network and confirming the legitimate association of the payment account with the subscriber occurs over a second network.

18. The system of claim 8, wherein the payment request is a first payment request, and wherein the processor is configured to execute additional software instructions to:

prior to completing the confirmation of the legitimate association of the payment account with the subscriber;

receive a second payment request on behalf of the subscriber specifying the payment account as the source of funds,

determine that the second payment request does not comply with at least one pre-acceptance transaction rule, and

transmit a message to the subscriber informing the subscriber the second payment request is not valid.

19. The system of claim 18, wherein the processor is configured to execute additional software instructions to:

after confirming the legitimate association of the payment account with the subscriber;

receive a third payment request, wherein the third payment request is a re-submission of the second payment request, and

directing payment in accordance with the third payment request.

23. The system of claim 8, wherein the software instructions for the processor confirming the legitimate association of the payment account with the subscriber includes initiating at least one debit or credit transaction against the payment account and subsequently receiving transaction information from the subscriber, and wherein the transaction information includes or is associated with an attribute of the at least one debit or credit transaction.

24. The system of claim 23, wherein the software instructions for the processor initiating at least one debit or credit transaction against the payment account includes initiating at least one debit transaction and at least one credit transaction against the payment account, wherein each debit or credit transaction has an amount, and wherein the sum of the amounts of the at least one credit transaction offsets the sum of the amounts of the at least one debit transaction.

25. The system of claim 23, wherein the software instructions for the processor initiating at least one debit or credit transaction against the payment account includes initiating at least one debit or credit transaction against the payment account, wherein the number of the debit or credit transactions initiated is determined by generating at least one random number.

15. A system, comprising:

means for receiving, from a subscriber, identification of a payment account to be used in fulfilling payment requests submitted by a subscriber to the service provider;

means for, responsive to receiving the identification of the payment account, confirming a legitimate association of the payment account with the subscriber;

means for storing an indication that the payment account is confirmed as a confirmed account for use in funding future payment requests from the subscriber upon confirming the legitimate association of the payment account with the subscriber; and

means for prior to storing the indication that the payment account is confirmed as a confirmed account;

receiving a payment request on behalf of the subscriber specifying the payment account as the source of funds, the payment account being unconfirmed prior to storing the indication that the payment account is confirmed,

determining, by the service provider system, that the unconfirmed payment account is not indicated as a confirmed account,

in response to determining that the unconfirmed payment account is not indicated as a confirmed account, determining that the payment request complies with at least one pre-acceptance transaction rule, wherein each of the at least one pre-acceptance transaction rule specifies at least one respective criterion for allowing payment request processing prior to storing the indication that the unconfirmed payment account is confirmed for use in funding future payment requests from the subscriber, and

directing payment from the unconfirmed account in accordance with the payment request after determining that the payment request complies with the at least one pre-acceptance transaction rule.