System and method for intraday netting payment finality

Abstract

A system is provided for continuous intraday final settlement of payment orders among a plurality of financial-institution participants. The system includes a central controlling agent, including a central computer operable to communicate electronically with satellite computer stations of the plurality of participants to receive payment orders therefrom, and to control release of payments among the plurality of participants; and means for storing a plurality of prefunded balances in a prefunded balance account, each balance representing the right of one of the participants to payment from the prefunded balance account and containing an initial prefunded balance for each participant at the start of each business day.

Claims

What is claimed is:

1. A system for continuous intraday final settlement of payment orders among a plurality of financial-institution participants, each having an associated satellite computer station operable to transmit payment orders electronically and each being operable to function as a payment receiving participant and a payment sending participant; said system comprising:

(a) a central controlling agent, including a central computer operable to communicate electronically with the satellite computer stations of the plurality of participants to receive payment orders therefrom, and to control release of payment orders among the plurality of participants; and

(b) means for storing a plurality of prefunded balances in a prefunded balance account, each balance representing the right of one of the participants to payment from the prefunded balance account and containing an initial prefunded balance for each participant at a start of each business day,

wherein said central computer is operable on a continuous basis:

(1) upon receipt of a payment order by said central controlling agent from one of said participants, operating as a sending participant, for payment to another of said participants, operating as a receiving participant, to categorize each received payment order as small if it is less than a predetermined percentage of one of the initial prefunded balance for the associated sending participant and the initial prefunded balance for the associated receiving participant, and as large otherwise;

(2) to store the received payment order in a queue maintained by said central computer;

(3) to monitor the queue for previously stored small payment orders as candidates for immediate release for payment;

(4) to determine if release of a candidate small payment order for payment will cause available balances for both the sending participant and the receiving participant associated with the candidate small payment order to fall within respective predetermined limits;

(5) if the determination in step (4) is positive, to release the candidate small payment order by debiting the available balance of the sending participant and crediting the available balance of the receiving participant by the amount of the associated candidate small payment order;

(6) to monitor the queue for previously stored target large payment orders for payment from a sending participant to a receiving participant;

(7) to release a target large payment order stored in the queue by performing multilateral batching (i) by forming a first tree comprised of the target payment order and, if necessary, helper payment orders in a direction towards the sending participant of the target payment order, from at least one sending participant other than the sending participant of the target large payment order; (ii) by forming a second tree comprised of the target payment order and, if necessary, helper payment orders in a direction away from the receiving participant of the large target payment order, to at least one receiving participant other than the receiving participant of the target payment order; (iii) debiting the available balances of the sending participant of the target large payment order and of the sending participants of the helper payment orders in a multilateral batch comprising the target and helper payment orders of the first and second trees by the amounts of each respective payment order; and (iv) crediting the balances of the receiving participant of the target large payment and of the receiving participants of the helper payment orders in the multilateral batch by the amounts of the respective payment orders; the multilateral batch having been chosen so that after the payment orders comprising the first and second trees are released, the resulting position in the available balance of each participant involved in the multilateral batching falls within predetermined limits.

2. The system according to claim 1, wherein the central computer system is operable to selectively offset, in a bilateral batch, the amount of a target large payment order by searching the queue for a previously queued second payment order from the associated receiving participant of the target large payment order; to generate a pseudo-payment order in an amount of a net difference between the target large payment order and the second payment order; and to store the pseudo-payment order in the queue.

3. The system according to claim 2, wherein the central computer is operable to select the second payment order in the bilateral batch within a range between half as large as the target large payment order of the bilateral batch and twice as large as the target large payment order.

4. The system according to claim 1, wherein the central computer is operable to select small payment orders for release from the queue in accordance with a first-in first-out queue discipline.

5. The system according to claim 4, wherein the central computer is operable to select small payment orders for release from the queue in accordance with the Gale-Shapley algorithm.

6. The system according to claim 1, wherein the central computer selects the predetermined percentage for categorizing queued payment orders as small payment orders to be 80% of the lesser of the initial prefunded balance for the associated sending participant and the initial prefunded balance for the associated receiving participant.

7. The system according to claim 1, wherein the central computer is operable to set the predetermined limits such that the available balance of any of the prefunded balances cannot exceed 200% of the initial prefunded balance or go below zero.

8. The system according to claim 1, wherein the small category of payment orders is divided into subcategories medium and very small, wherein only large and medium payment orders are eligible to become helper payment orders.

9. The system according to claim 8, wherein the queue comprises a plurality of queues, and wherein very small, medium and large payment orders are stored in various ones of said plurality of queues on the basis of the size of the respective payment orders.

10. A method for continuous intraday final settlement of payment orders among a plurality of financial-institution participants, each having an associated satellite computer station operable to transmit payment orders electronically and each being operable to function as a payment receiving participant and a payment sending participant by a central controlling agent including a central computer operable to communicate electronically with the satellite computer stations of the plurality of participants to receive payment orders therefrom, and to control release of payment orders among the plurality of participants; and means for storing a plurality of prefunded balances in a prefunded balance account, each balance representing the right of one of the participants to payment from the prefunded balance account and containing an initial prefunded balance at a start of each business day, said method comprising the steps of:

(1) upon receipt of a payment order by the central controlling agent from one of the participants, operating as a sending participant, for payment to another of the participants, operating as a receiving participant, categorizing each received payment order as small if it is less than a predetermined percentage of one of the initial prefunded balance for the associated sending participant and the initial prefunded balance for the associated receiving participant, and as large otherwise;

(2) storing the received payment order in a queue maintained by the central computer;

(3) monitoring the queue for previously stored small payment orders as candidates for immediate release for payment;

(4) determining if release of a candidate small payment order for payment will cause available balances for both the sending participant and the receiving participant associated with the candidate small payment order to fall within respective predetermined limits;

(5) if the determination in step (4) is positive, releasing the candidate small payment order by debiting the available balance of the sending participant crediting the available balance of the receiving participant by the amount of the associated candidate small payment order;

(6) monitoring the queue for previously stored target large payment orders for payment from a sending participant to a receiving participant;

(7) releasing a target large payment order stored in the queue by performing multilateral batching (i) by forming a first tree comprised of the target payment order and, if necessary, helper payment orders in a direction towards the sending participant of the target payment order, from at least one sending participant other than the receiving participant of the target large payment order; (ii) by forming a second tree comprised of the target payment order and, if necessary, helper payment orders in a direction away from the receiving participant of the large target payment order, to at least one receiving participant other than the receiving participant of the target payment order; (iii) debiting the available balances of the sending participant of the target large payment order and of the sending participants of the helper payment orders in a multilateral batch comprising the target and helper payment orders of the first and second trees by the amounts of each respective payment order; and (iv) crediting the balances of the receiving participant of the target large payment and of the receiving participants of the helper payment orders in the multilateral batch by the amounts of the respective payment orders; the multilateral batch having been chosen so that after the payment orders comprising the first and second trees are released, the resulting position in the available balance of each participant involved in the multilateral batching falls within predetermined limits.

11. The method according to claim 10, further comprising the steps of:

selectively offsetting, in a bilateral batch, the amount of the target large payment order by searching the queue for a previously queued second payment order from the associated receiving participant of the target large payment order;

generating a pseudo-payment order in an amount of a net difference between the target large payment order and the second payment order; and

storing the pseudo-payment order in the queue.

12. The method according to claim 11, wherein the second payment order in the bilateral batch must fall within a range between half as large as the target large payment order of the bilateral batch and twice as large as the target large payment order.

13. The method according to claim 10, wherein small payment orders are selected for release from the queue in accordance with a first-in first-out queue discipline.

14. The method according to claim 13, wherein small payment orders are selected for release from the queue in accordance with the Gale-Shapley algorithm.

15. The method according to claim 10, wherein the predetermined percentage for categorizing queued payment orders as small payment orders is selected to be 80% of the lesser of the initial prefunded balance for the associated sending participant and the initial prefunded balance for the associated receiving participant.

16. The method according to claim 10, wherein the predetermined limits are set such that the available balance of any of the prefunded balances cannot exceed 200% of the initial prefunded balance or go below zero.

17. The method according to claim 10, wherein the small category of payment orders is divided into subcategories medium and very small, wherein only large and medium payment orders are eligible to become helper payment orders.

18. The method according to claim 17, wherein the queue comprises a plurality of queues, and wherein very small, medium and large payment orders are stored in various ones of said plurality of queues on the basis of the size of the respective payment orders.

19. A computer-readable medium storing code executable by a central computer, the code controlling the central computer to perform a method for continuous intraday final settlement of payment orders among a plurality of financial-institution participants, each having an associated satellite computer station operable to transmit payment orders electronically and each being operable to function as a payment receiving participant and a payment sending participant, the central computer forming a part of a central controlling agent and being operable to communicate electronically with the satellite computer stations of the plurality of participants to receive payment orders therefrom, to control release of payment orders among the plurality of participants, and to control means for storing a plurality of prefunded balances in a prefunded balance account, each balance representing the right of one of the participants to payment from the prefunded balance account and containing an initial prefunded balance for each participant at a start of each business day, the method comprising the steps of:

(1) upon receipt of a payment order by the central controlling agent from one of the participants, operating as a sending participant, for payment to another of the participants, operating as a receiving participant, categorizing each received payment order as small if it is less than a predetermined percentage of one of the initial prefunded balance for the associated sending participant and the initial prefunded balance for the associated receiving participant, and as large otherwise;

(2) storing the received payment order in a queue maintained by the central computer;

(3) monitoring the queue for previously stored small payment orders as candidates for immediate release for payment;

(4) determining if release of a candidate small payment order for payment will cause available balances of both the sending participant and the receiving participant associated with the candidate small payment order to fall within respective predetermined limits;

(5) if the determination in step (4) is positive, releasing the candidate small payment order by debiting the available balance of the sending participant and crediting the available balance of the receiving participant by the amount of the associated candidate small payment order;

(6) monitoring the queue for previously stored target large payment orders for payment from a sending participant to a receiving participant;

(7) releasing a target large payment order stored in the queue by performing multilateral batching (i) by forming a first tree comprised of the target payment order and, if necessary, helper payment orders in a direction towards the sending participant of the target payment order, from at least one sending participant other than the sending participant of the target large payment order; (ii) by forming a second tree comprised of the target payment order and, if necessary, helper payment orders in a direction away from the receiving participant of the target large payment order, to at least one receiving participant other than the receiving participant of the target payment order; (iii) debiting the available balances of the sending participant of the target large payment order and of the sending participants of the helper payment orders in a multilateral batch comprising the target and helper payment orders of the first and second trees by the amounts of each respective payment order; and (iv) crediting the available balances of the receiving participant of the target large payment and of the receiving participants of the helper payment orders in the multilateral batch by the amounts of the respective payment orders; the multilateral batch having been chosen so that after the payment orders comprising the first and second trees are released, the resulting position in the available balance of each participant involved in the multilateral batching falls within predetermined limits.

20. The computer-readable medium according to claim 19, further comprising code to cause the central computer to perform the steps of:

selectively offsetting, in a bilateral batch, the amount of the target large payment order by searching the queue for a previously queued second payment order from the associated receiving participant of the target large payment order;

generating a pseudo-payment order in an amount of a net difference between the target large payment order and the second payment order; and

storing the pseudo-payment order in the queue.

21. The computer-readable medium according to claim 20, wherein the second payment order in the bilateral batch must fall within a range between half as large as the target large payment order of the bilateral batch and twice as large as the target large payment order.

22. The computer-readable medium according to claim 19, wherein small payment orders are selected for release from the queue in accordance with a first-in first-out queue discipline.

23. The computer-readable medium according to claim 22, wherein small payment orders are selected for release from the queue in accordance with the Gale-Shapley algorithm.

24. The computer-readable medium according to claim 19, wherein the predetermined percentage for categorizing queued payment orders as small payment orders is selected to be 80% of the lesser of the initial prefunded balance for the associated sending participant and the initial prefunded balance for the associated receiving participant.

25. The computer-readable medium according to claim 19, wherein the predetermined limits are set such that the available balance of any of the prefunded balances cannot exceed 200% of the initial prefunded balance or go below zero.

26. The computer-readable medium according to claim 19, wherein the small category of payment orders is divided into subcategories medium and very small, wherein only large and medium payment orders are eligible to become helper payment orders.

27. The computer-readable medium according to claim 26, wherein the queue comprises a plurality of queues, and wherein very small, medium and large payment orders are stored in various ones of said plurality of queues on the basis of the size of the respective payment orders.

Description

BACKGROUND OF THE INVENTION

I. Field of the Invention

The invention relates to a system and method of receiving and transmitting electronic payments between and among financial institutions in which payments are final when transmitted.

II. Description of the Related Art

A person (individual or corporate) making a payment in the United States has an array of payment instruments from which to choose. It is likely that most single transactions still are paid for in cash (coin and currency). There are also checks and other paper instruments (travelers' checks, money orders, and official checks) and debit and credit entries processed by automated clearing houses ("ACH", a computer based, batch processing electronic payment mechanism that supports both credit and debit transfers and is used primarily for low-dollar transactions such as direct deposit of payroll and benefit payments and mortgage and insurance premium payments that can be scheduled some time in advance and that are not time-critical). The largest payments, however, usually are sent by funds transfers. Each day, the two principal funds transfer systems, Fedwire and CHIPS ("Clearing House Interbank Payments System"), transfer hundreds of thousands of payments worth more than $2 trillion. The average size of a funds transfer is very large--about $6 million on CHIPS and $3 million on Fedwire.

Funds transfers can involve a number of different parties. Many transfers take place to settle obligations of two banks, such as the delivery or return of "fed funds" (a bank's deposits with its Federal Reserve Bank). In these cases, only the two banks will be involved. Banks also transfer funds on behalf of customers. These transfers may be to another person, either at the same bank or at another bank. Sometimes a customer will move funds between two of its own accounts, either at different banks or at the same bank, for example, from local accounts used to collect bills to a cash concentration account or to a payroll account.

A funds transfer may involve a single bank (a "book-transfer") or it may involve several. In most cases, the originator will not specify the method for carrying out his payment order, and the originator's bank will select the most efficient way to have the funds sent to the beneficiary, including choosing a network or intermediary bank.

For simplicity in analyzing how the funds transfer system works, one example will be used: Customer X orders his bank, Bank A, to pay $10,000 to the account of Customer Y at Bank B. The following will look at the different stages of the funds transfer and the various options open to the parties at each stage: How Customer X transmits the payment order to Bank A; how Bank A transmits the payment order to Bank B; how Bank B notifies Customer Y and makes the funds available to him; and how Banks A and B settle their balances.

A. Origination Of Funds Transfer

There are many ways for a person to order his bank to send a funds transfer. Probably the largest number of funds transfers, and certainly those involving the highest monetary value, are those originated by corporations with a direct computer-to-computer link to the bank. In these cases, the customer enters the payment instructions into his computer, and the computer sends the payment order directly to his bank's computer. The bank's computer "edits" the payment order. If the payment order fails one of the edits, for example, if mandatory information has not been included in the payment order, the computer routes the payment order to an operator's screen, and the operator makes any necessary corrections or seeks (or has someone else in the bank seek) clarification from the customer. A similar procedure is used for customers that use a personal computer to transmit payment messages to the bank.

Individuals generally must go to the bank to fill out a form and pay a fee for a funds-transfer service. Individuals with large bank balances and small companies may have a personal banker or account officer. To send a funds transfer, these persons telephone the officer and give the transfer instructions, usually after the authenticity of the call has been established through code word or call-back procedures. The officer either enters the payment order directly into the bank's computer at his own computer terminal or fills out a form for delivery to the bank's funds transfer department where it is entered in the bank's computer. Many banks are now offering "home banking" products that allow individual consumers to deal directly with the bank's computer by way of their own personal computers.

B. Originator's Bank's Acceptance Of Payment Order

Once the payment order has been entered into the bank's funds-transfer computer system and passes the initial edits, it is checked against the customer's demand account balance. If the balance is sufficient, the bank executes the payment order by issuing a corresponding payment order to a funds-transfer network or the next bank in the funds transfer. If the customer does not have a sufficient balance in his account, the computer checks to see if the customer has an available credit line. If so, the payment is released; if not, the payment is held pending receipt of funds to cover the payment. If covering funds have not been received by the late afternoon (usually 2:00 to 4:00 P.M.), the payment order may be referred to a credit officer who will decide whether to extend additional credit to the customer to enable the payment to be made.

If a payment order has not been sent on by the end of the execution date (the date that the bank may properly issue a payment order in execution of the sender's order), the bank will normally reject it by sending a notice of the rejection to the sender.

C. Transfers Between Banks

If there is more than one bank involved in a funds transfer, it is necessary for funds to be moved from one bank to the other. In the U.S., this can be accomplished by using one of the two large-dollar funds transfer networks to be discussed below, or through the adjustment of correspondent balances.

1. FEDWIRE

Fedwire is the funds transfer network operated by the 12 Federal Reserve Banks. It is a real-time, gross settlement system, meaning that the payment is final and irrevocable at the time the Federal Reserve Bank credits the account on its books of the receiving bank. There is thus no risk that the receiving bank will suffer a loss if it makes the funds available to the beneficiary and the sender cannot pay the amount of the payment order to its Federal Reserve Bank. In such a case, the Federal Reserve Bank would suffer the loss, not the receiving bank.

Fedwire is available to any depository institution that has a reserve or clearing account at a Federal Reserve Bank. There are currently about 10,000 such institutions. About 7,000 of these institutions have an "on-line" connection to their Federal Reserve Banks, most through a "Fedline" terminal linked to the Federal Reserve Bank by dial-up telephone connections or leased lines; about 200 of the largest institutions have direct computer-to-computer interfaces. An institution with an on-line connection may send and receive Fedwire payment orders to and from the Fedwire computer automatically without manual processing by Federal Reserve Bank personnel. The Federal Reserve Bank will send a computer message to the sender acknowledging the payment order. About 99 percent of Fedwire transfers originate with on-line payment orders.

"Off-line" transactions usually require the sender to telephone its Federal Reserve Bank, with the payment order authenticated by the use of codes or other procedures established by the Federal Reserve Bank. These telephone calls are also tape recorded. Following authentication, Federal Reserve Bank personnel enter the payment order into the Fedwire computer. Because of the manual processing involved, the Federal Reserve Banks charge significantly more for off-line transfers than for on-line ones.

A payment order received by a Federal Reserve Bank is routed to a Fedwire processing computer. This computer performs system edits and routes the payment order to the receiving Federal Reserve Bank, which automatically credits the receiving bank's account and sends an advice to the receiving bank.

Example 1 below shows the progress of a funds transfer involving a Fedwire payment order, noting the appropriate accounting entries. Settlements between Federal Reserve Banks are also discussed below.

EXAMPLE 1

Fedwire transfer involving two Federal Reserve Banks, in which Customer X orders Bank A to pay $10,000 to Customer Y of Bank B.

Step 1: Customer X sends payment order to Bank A; Bank A debits Customer X's account and sends Fedwire payment order to FRB1.

    ______________________________________
    Bank A
    Assets            Liabilities
    ______________________________________
    Due from FRB      Deposits
    -10,000           Customer X -10,000
    ______________________________________

    ______________________________________
    FRB 1
    Assets               Liabilities
    ______________________________________
    Interdistrict settlement
                         Deposits
    account -10,000      Bank A -10,000
    ______________________________________

    ______________________________________
    FRB 2
    Assets               Liabilities
    ______________________________________
    Interdistrict settlement
                         Deposits
    account +10,000      Bank B +10,000
    ______________________________________

    ______________________________________
    Bank B
    Assets            Liabilities
    ______________________________________
    Due from FRB2     Deposits
    +10,000           Customer Y +10,000
    ______________________________________

    ______________________________________
    Bank A
    Assets             Liabilities
    ______________________________________
    Note: Obligation   Deposits
    to pay $10,000 which
                       Customer X -10,000
    is offset by obligation
    of Bank B to pay for
    its transfers to Bank A.
    ______________________________________


______________________________________
    Bank A
    Assets             Liabilities
    ______________________________________
    Note: Entitlement to
                       Deposits
    receive $10,000 from
                       Customer Y +10,000
    Bank A, which is
    offset by Bank B's
    obligation to pay for
    its transfers to Bank A.
    ______________________________________

    ______________________________________
    Bank A
    Assets            Liabilities
    ______________________________________
    Due from Bank B   Deposits
    -10,000           Customer X -10,000
    ______________________________________

    ______________________________________
    Bank B
    Assets           Liabilities
    ______________________________________
                     Deposits
                     Bank A -10,000
                     Customer Y +10,000
    ______________________________________

    ______________________________________
    Bank A
    Assets           Liabilities
    ______________________________________
                     Deposits
                     Bank B +10,000
                     Customer X -10,000
    ______________________________________

    ______________________________________
    Bank B
    Assets              Liabilities
    ______________________________________
    Due from A          Deposits
    +10,000             Customer Y +10,000
    ______________________________________

    ______________________________________
    Bank A
    Assets           Liabilities
    ______________________________________
                     Deposits
                     Customer X -10,000
                     Customer Y +10,000
    ______________________________________

                  TABLE I
    ______________________________________
    Date            Reason Chosen
    ______________________________________
    January 21, 1997
                    Day after the 3 day Martin Luther
                    King Day weekend. That date had
                    the highest volume recorded on
                    CHIPS up until then.
    March 27, 1997  The Thursday before Good Friday.
                    Because much of Europe was to be
                    closed for Good Friday, this was
                    effectively the last business day
                    of the quarter in these
                    countries. Hence, the usual as
                    elevated quarter-end CHIPS volume
                    was observed on that day.
    March 31, 1997  This was Easter Monday, which is
                    a holiday in Europe, and a low
                    volume day for CHIPS.
    April 11, 1997  That day, one of the participants
                    had an usually large credit
                    position.
    May 27, 1997    The day after the Memorial Day
                    Weekend. CHIPS had the usual
                    post-holiday (heavy) volume that
                    day.
    June 16, 1997   A typical day for CHIPS.
    June 18, 1997   A typical day for CHIPS.
    July 3, 1997    This was the day before the
                    Independence Day Weekend. CHIPS
                    had the elevated volumes typical
                    for the day before a holiday.
    November 28, 1997
                    This was the day after
                    Thanksgiving. CHIPS volume was
                    at a historic high for that day.
    ______________________________________

                  TABLE II
    ______________________________________
                         Total Number
                         of Pmt.    Total of
              % Dollars  Orders     Pmt. Orders
    Date      Released   (x 10.sup.5)
                                    (x 10.sup.12 $)
    ______________________________________
    21-Jan-97 96.23%     4.187      2.178
    27-Mar-97 95.79%     2.716      1.856
    31-Mar-97 91.45%     1.040      0.509
    11-Apr-97 95.38%     2.330      1.416
    27-May-97 95.62%     3.967      2.039
    16-Jun-97 95.88%     2.579      1.594
    3-Jul-97  94.89%     2.289      1.467
    28-Nov-97 97.48%     4.570      2.237
    ______________________________________

                  TABLE III
    ______________________________________
    ABA #         A      B         C     D
    ______________________________________
    Cap (millions)
                  28.05  10        25.5  25.5
    Amt, pmt orders sent
                  71.03  116.91    742.43
                                         463.05
    Amt, pmt orders rec'd
                  13.5   47.55     421.14
                                         256.44
    Amt, large orders sent
                  45     37.66     669.17
                                         400.96
    Amt, large orders rec'd
                  0      16.11     360.84
                                         230.04
    Amt, small orders sent
                  26.03  79.25     73.26 62.09
    Amt, small orders rec'd
                  13.5   31.44     60.3  26.4
    Ratio, sent/rec'd
                  5.261  2.459     1.763 1.806
    ______________________________________


              TABLE IV
    ______________________________________
    ABA # of 4 randomly
    chosen participants
                 E        F        G      H
    ______________________________________
    Cap (millions)
                 10.2     15.29    38.25  127.5
    Amt, pmt orders sent
                 2276.07  11427.82 2944.07
                                          107495.9
    Amt, pmt orders rec'd
                 2126.35  11405.97 2734.84
                                          106617.5
    Amt, large orders sent
                 1519.42  9207.76  1806.93
                                          56683.22
    Amt, large orders rec'd
                 1544.58  9305.62  1606.73
                                          57328.35
    Amt, small orders sent
                 756.65   2220.06  1137.14
                                          50812.69
    Amt, small orders rec'd
                 581.77   2100.35  1128.11
                                          49289.17
    Ratio, sent/rec'd
                 1.07041  1.00192  1.07651
                                          1.00824
    ______________________________________

                  TABLE V
    ______________________________________
           P1   P2           P3     P4
    ______________________________________
    P1              373          273  879
    P2       237                      690
    P3       946    505               436
    P4              430          120
    ______________________________________