WO2000036571A1

WO2000036571A1 - Euro payment routing and intra-day flow control system and method

Info

Publication number: WO2000036571A1
Application number: PCT/GB1999/004159
Authority: WO
Inventors: Nigel Knight; Richard Smith; Lawrence Drake; Matthew Lynch
Original assignee: The Chase Manhattan Bank
Priority date: 1998-12-15
Filing date: 1999-12-10
Publication date: 2000-06-22
Also published as: HK1044841A1; AU1670200A; EP1141908A1

Abstract

A system and method of routing Euro payments through one of the plurality of clearing channels. Payment transactions originating at branches of a financial institution are forwarded to and processed by a central hub located within the financial institution. The method includes a routing process and a flow control process. The routing and flow control processes are executed at the central hub. The routing process determines which clearing channel to use based on a number of factors such as the availability of the channel, customer instructions for routing, the membership of the destination bank, agreements with the destination bank, priorities, and the type of payment. The flow control process monitors the balance for a clearing member within a selected channel, and the balance of the channel as a whole. Depending on whether the balances exceed predetermined limits, the flow control process will either hold a routed payment or release it down the channel. The system and method allows customers to request specific Euro clearing mechanisms to be used for the Euro payment.

Description

EURO PAYMENT ROUTING AND INTRA-DAY FLOW CONTROL

SYSTEM AND METHOD

FIELD OF THE INVENTION

The present invention generally relates to systems and methods for the routing of payment transactions between financial institutions and more particularly to a system and method for routing and controlling the flow of Euro payments through a plurality of clearing channels.

BACKGROUND OF THE INVENTION

Effective January 1, 1999, the Euro was established as an official currency of many of the countries of the European Economic Union (EU). Currently, the members of the EU which have converted to the Euro are Germany, France, Spain, Belgium, Ireland, Italy, Luxembourg, The Netherlands, Austria, Portugal and Finland. The previous currencies of these countries will continue to be available for a transition period. They will be denominations of the Euro at fixed conversion rates. The Euro will have broad effects throughout Europe even though every

European is not participating from the beginning. At the end of 2001 the previous currencies will cease to exist for electronic and account balance purposes. In the year 2002, the eleven European Union member states listed above will officially replace their previous currency notes and coins by Euro notes and coins.

For each national currency (e.g., French Francs) the conversion rate to the Euro has been set and is fixed (will not fluctuate). Foreign exchange operations in Euros have now begun. All new public debt issues in each of the EU countries will be in Euros and many outstanding ones will be re-denominated. National bank notes and coins will not yet be replaced, but banking is possible in both Euro and the national currency.

By January 1, 2002, Euro notes and coins will gradually replace notes and coins in the national currencies. The national currencies must be withdrawn by July 1, 2002 at the latest. For companies outside of the financial sector, the main costs in converting to the Euro will be adapting information systems and, quite possibly reorganizing structures and procedures. The costs in the financial sector will be higher. Banks have had to be ready to operate in the Euro from January 1, 1999, in order to be able to handle payments by companies and individuals and to cooperate with the European Central Bank, ECB, in the implementation of monetary policy. This has required banks to adapt their computer systems to handle the new currency, to reorganize their operations in financial markets, to train staff and to develop new product and services for companies and individuals.

While no one is compelled to use the Euro before January 1, 2002, banks have had to prepare for the possibilities that some, many, or all of their customers might wish to do so. For those customers wanting Euro services before the year 2002, banks may offer Euro accounts. During the transitional period (January 1, 1999 through December 31, 2001), it would be possible for customers to keep their accounts in national currency and the banks will take care of receiving and making any Euro payments on these accounts at the fixed conversion rate.

The Trans-European Automated Real-Time Gross settlement Express Transfer (TARGET) system is the electronic payment system which is a crucial instrument for the European Central Bank's conduct of monetary policy. It is one mechanism which enables the cross boarder transfer of funds between banks in real time and allows payments to be made through the Euro zone at low cost with high security and very short processing times. TARGET also helps the development of sound and efficient payment mechanisms in the single market. Together with the fifteen National Central Banks (NCBs) of the member countries, the ECB is part of the European System of Central Banks (ESCB) whose primary objective is mamtaining price stability. The ESCB's basic tasks includes defining and implementing monetary policy for the Euro, conducting foreign exchange operation and holding and managing the official foreign reserves of the membered states. The ECB also promotes the smooth operation of payment systems and contributes to the work of the relevant national authorities and supervising credit institutions and stability of the financial system.

Prior to the introduction to the Euro, there were approximately fourteen different systems for same day value clearing of payments in the 11 countries. Same day value clearing refers to the system and processes by which high value transactions are typically executed. With the introduction of the Euro, there are approximately nineteen same day clearing systems, but the clearing process now takes place in Euros, and not in any national currency. Furthermore, prior to the introduction of the Euro, clearing transactions in a particular currency were limited to same day clearing systems in that currency and these typically only exist in the country of the currency. For example, if two German banks were processing a payment between two customers in French Francs, the transaction had to have been cleared through the French clearing system.

Now, this payment can be made through any of the 19 clearing systems as all of them are required to conduct transactions in Euros.

The nineteen different clearing systems are constituted by fifteen Real Time Gross Settlement Systems (RTGS) and four non RTGS systems. Figure 1 illustrates a clearing process prior to the introduction of the Euro. The example depicted in Figure 1 is a clearance between two German clearers 10, 15. As illustrated in this Figure, there were only two clearing systems EAF-220 and ELS 25 by which these two German clearers could process high value payments.

Upon the introduction of the Euro, as depicted in Figure 2, a clearing between two Euro clearers 30, 35 can now take place through approximately 19 different same day clearing systems. These systems include the four non RTGS systems 40, and 15 RTGS systems 45. By using an RTGS 45 a Euro clearer 30, 35 can route a payment through the

TARGET system 50 to reach a destination Euro clearer 30, 35. Furthermore, as illustrated in Figure 2, a Euro clearer 30, 35 can use a correspondent financial institution 55 to directly clear a payment or use the correspondent 55 to clear a payment through an RTGS or non RTGS system 60 to which the Euro clearer is not a member. A clearer 30, 35 will be a member of one or more of the RTGS or non RTGS systems.

SUMMARY OF THE INVENTION

The present invention is a system and method of routing Euro payments through one of the plurality of clearing channels. The method of the present invention is accomplished by two main processes, a routing process, and a flow control process. The routing process decides which clearing channel to use based on a number of factors such as the availability of the channel, customer instructions for routing, the clearing system memberships of the destination bank, agreements with the destination bank, priorities, and the type of payment. The flow control process monitors the balance for a clearing member within a selected channel, and the balance of the channel as a whole. Depending on whether the balances exceed predetermined limits, the flow control process will either hold a routed payment or release it down the channel. The system and method will allow customers to request specific Euro clearing mechanisms to be used for the Euro payment. In the preferred embodiment, all clearing transactions for a financial institution will be processed by a central legal hub. This is likely to require cross border membership of clearing systems. The routing and flow control processes are executed at this central hub. In an alternative embodiment, the routing clearing system memberships/access can be accomplished on a branch by branch basis, but with central control monitoring the routing and flow control.

BRIEF DESCRIPTION OF THE DRAWINGS

For the purposes of illustrating the present invention, there is shown in the drawings a form which is presently preferred, it being understood however, that the invention is not limited to the precise form shown by the drawing in which:

Figure 1 illustrates a prior art method of clearing a payment;

Figure 2 depicts the prior art channels of clearance after the introduction of the Euro;

Figure 3 illustrates an overview of the system of the present invention.

Figure 4 illustrates a preferred embodiment of the system of the present invention.

Figure 5 is a flow chart of the preprocessing, routing and flow control processing at a hub location. Figure 6 shows the initial flow chart of the routing process.

Figure 7 is a flow chart of the routing process when no route has been specified.

Figure 8 depicts the decision process for selecting a channel where multiple are available. Figure 9 is a table containing details of the members of the clearing systems.

Figure 10 illustrates a table containing the details of all the channels through which the hub can directly or indirectly process a payment.

DETAILED DESCRD7TION OF THE INVENTION

An overview of a preferred embodiment of the present invention is illustrated in Figure 3. Element 100 represents the global operations of a financial institution such as a bank. Elements 105-115 represent the branches or subsidiaries of the bank distributed throughout the world. Element 120 represents a central legal entity, a hub, of the bank. In a preferred embodiment of the invention, hub 120 is a branch or subsidiary of the bank itself.

Elements 125-150 represent six specific clearing channels to which the hub 120 is connected. Element 45 generically represents any RTGS clearing system while element 40 generically represents the MLNS systems. As in the prior art depicted in Figure 2, the hub 120 is also connected to correspondent financial institutions 55. Furthermore, each of the RTGSs 45, 125, 130 and 135 are illustrated as being connected to the TARGET system 50. As previously explained, through the TARGET system 50 any of the RTGSs are able to clear a payment through another RTGS. Other RTGS 45 and other non RTGS 40 clearing systems are important because they illustrate the flexibility of this invention. It is easy to add or drop clearing systems as appropriate with negligible impact on customers. This flexibility in using alternative channels is also very valuable in contingency situations.

Operationally, all of the same day value payments to be cleared from the financial institution 100 are forwarded from the various branches 105-115 to the central hub location 120. As the single hub location 120 receives all of the payments to be cleared, it has the ability to manage the clearance process for the entire financial institution 100. As will be more fully described below, this management function includes two primary components relating directly to the clearing channels, one for determining the routing of the payment through an appropriate channel, and one for controlling the flow of all of the financial institution's payments among all of the channels. Figure 4 schematically illustrates this payment routing and flow control portion 170 of the hub. Further illustrated in Figure 4 are the institutional and corporate customers 160 of the various branches 105-115 and hub branch 120.

The method executed by the hub 120 in processing payments is illustrated in Figure 5. Step 200 in Fig. 5 processes incoming electronic messages (payment instructions) received by the hub 120. Such messages are transferred between the branches 105-115 and the hub 120 and between the institutional and corporate customers 160 and the hub 120. These messages can take many forms. Alternatively, payment instructions may be handled manually in which they are entered for processing via Manual Payment Input 215. With respect to payments, the transaction normally contains all of the relevant information required to process the payment including at least an identification of the payor, the payee and the amount. Sometimes it is necessary to refer back to the transaction originator.

When one of the customers of the hub 120 (e.g., branches 105-115 or institutional or corporate customers 160) sends a payment instruction to the hub 120, the instruction may, but does not have to include routing instructions. For example, the customer of the hub might specify that the payment should be cleared through either RTGS or non RTGS without specifying the specific system to which routing can be made.

The customer of the hub 120 can signify RTGS or non RTGS and additionally specify the specific RTGS non RTGS channel for use in the routing. If a specific channel is identified, the hub 120 may or may not be a member of that specific channel. If the hub 120 is a member of that specific channel, the routing process described below will attempt to satisfy that specific request. If the hub 120 is not a member of the specific requested channel, the straight through processing 220 will set the payment type to CLG which indicates that the router is free to decide upon the route which the payment will take. Similarly, if the customer of the hub 120 does not specify any routing preferences, the payment type will be set to CLG. The straight through processing 220 also ensures that sufficient details are contained in the payment instruction from the customer of the hub such that once the transaction gets to the payment routing (described below) the router will have sufficient details to choose any of the available clearing channels without having to send the transaction for manual inspection and repair. The validation process in step 220 ensures that sufficient details are available to process the payment transaction through the preferred payment channel for the transaction. If the payment is for same day value, then any closed channels (past cut off) are ignored when detern ining the preferred channel. If the payment can be made through only one clearing system then step 220 will ensure that sufficient details are present to process the payment transaction through that clearing system. If the payment can be made through many clearing systems, the straight through processing step 220 will ensure that sufficient details exist to process the payment transaction through only the preferred clearing system.

Although the above has described the initial message processing 200 for messages sent from the branches 105-115 of the financial institution 100, similar rules apply if the payment instruction is coming directly from the institutional or corporate customers 160 of the hub 120 itself as depicted in Figure 4. This initial message and validation process 200 and the manual equivalent 215 are preferably also performed at each of the branches 105-115 as it receives payment instructions from its customers 160.

Initial message processing 200 also processes incoming messages from the clearing systems which contain credits for customers

160 of the financial institution 100 or for the financial institution 100 itself. When a credit comes through a channel, the credit must be processed in order to update the relevant control balances described below. To do this, the credit message identifies the clearing channel from which the credit came and the bank which sent the payment into the clearing channel. For credits received cross-border via TARGET the bank who sent the payment into the clearing channel will be the National Central Bank for that channel. The flow control process of the present invention described below is not interested in the particular customer 160 of the financial institution 100 for which the credit is destined (or for itself), flow control is only interested in the fact that a credit came in from a particular clearing channel. This is because flow control is only interested in maintaining balances on all of the channels and pay-banks and in keeping track of when a particular channel or pay-bank reaches its limit. The further processing of credits do not form part of the present invention and are not discussed herein.

In step 210, the initial message processing has identified outgoing payments received from customers of the hub 120.

Payment instructions may be received via automated (steps 200-210) or manual (step 215) means. Certain automated instructions may be of such a format that they are printed and processed as manual instructions. With transactions which are processed automatically, there are sophisticated processes to try to process these transactions without any manual intervention whatsoever. This is referred to as Straight Through Processing (STP) and the primary processing is in boxes 200, 210 and 220. Where such a transaction cannot be processed straight through, it will go to payment repair 225 where an operator will amend the transaction such that it can continue processing. Only those details which are invalid or missing need be manually entered as all other details from the electronic processing are available.

In extreme situations, it may be necessary to remove a transaction from the electronic processing and re-enter it as a manual instruction via Manual Payment Input 215. Manual Payment Input 215 performs an equivalent role to initial message processing 200 and the two subsequent stages 210 and 212, but on manual transactions. Manual transactions may originate as manual instructions, or from automated instructions which are printed on receipt, or from automated instructions which are removed from Payment Repair 225, or from certain other exception situations. Transactions entered via manual payment input 215 are subject to Verification 230 of critical data by a second operator. Similarly, transactions going though payment repair 225 are also subject to Verification 230. If an error is identified at Verification 230, the transaction is returned to an earlier stage for correction. Under certain conditions, automated instructions may be sent direct from Straight Through Processing 220 to Verification 230. In rare instances, transactions at subsequent stages may be returned to Payment Repair 225.

After Straight Through Processing 220 or verification 230, transactions are fully validated. In Forward Value 235, transactions may be held in a queue awaiting value date. When the value date occurs, the transactions are released from the forward queue. Transactions are subject to Risk Control 245 which ensures that the outgoing payments for a particular customer do not exceed the receipts by more than a defined limit. It is desirable to do this process as late as possible to keep the limits to the minimum. Full automation of all subsequent stages of processing, e.g. in payment routing and flow control, is essential to minimize the limits, and therefore the risk which is taken by the financial institution.

On entering the Router 250, a brief variable delay period is applied in case the last manual operation proved to be incorrect. This allows the operator to retrieve this transaction. Once this delay period has expired, the transaction becomes irrevocable, unless identified as an exception at one of the subsequent automated states. On becoming irrevocable, the transaction status is updated to (transaction) inactive. Element 250 is the Payment Router of the present invention.

Payment router 250 shall be discussed below in more detail, but in general the Payment Router 250 decides, based on a series of rules, how a payment should be routed through the various channels 280. Channels 280 generically describe the various RTGS and non RTGS channels previously described. Once the appropriate channel for transmission of the payment has been determined by Payment Router 250, the Payment Router 250 passes the payment transaction onto the flow control processes 255.

The first flow control method, bi-lateral limit validation 260, checks the proposed payment against the balance currently maintained by the hub 120 for the clearing member (the destination pay-bank on an individual channel basis). This will only apply where the transaction is being routed down a channel to which both the hub 120 and the destination pay bank are directly connected. All cross border transactions via TARGET will be accumulated against the National Central Bank which operates the system.

The flow control processing monitors the bi-lateral limits within the clearing systems. It maintains the total number and amounts of payment set to each destination clearer on a daily basis. If a proposed payment would put the totals over the limit which has been set for that destination clearer, then the flow control process puts a hold on the payment and will not let it be transferred out of the hub 120.

A second process 262 performed in the Flow Control module 255 looks at the maximum amount for an individual payment through each channel 280. Transactions which are above this maximum level require manual action.

The third process 265 performed in the flow control method 255 looks at the balance for the selected channel as a whole. In steps 260- 265, it is determined whether or not the proposed payment transaction exceeds set limits. If the proposed payment would exceed one of these predetermined limits in any of theses steps 260-265, the determination of the fate of the proposed payment may be determined in an on-line flow control process 270. Alternatively there are automated re-try processes within the bi-lateral 260 and overall checks 265 which are invoked periodically during the day to take into account each new credit received for the relevant channel 280.

In the on-line flow control process 270, an operator manually reviews the transaction and the current circumstances which caused the transaction to exceed the predetermined limits. The operator may have additional knowledge by which he or she may determine that a payment may be passed on to a particular channel even though its clearing will exceed the predetermined limits. For example, the operator might have knowledge that a particular credit has not yet been posted to the channel balance and that the processing of the proposed payment transaction will not be denied by the channel because of excess debits. At this stage, in rare instances, the operator may need to return the payment to Payment Repair 225.

The on-line flow control function 270 also provides for inquiring on and controlling payments held at the various stages of the flow control checks 260, 265. The on-line flow control process 270 is manually operated by the operators at the hub 120. Using this on-line system 270 the operators are able to select one or more of the clearing queues in order to display all of the held payments. Additionally, the operators can manually release any of the queued payments down the specified channel 280 if 5 required. Furthermore, the operators can manually put a payment back into the Payment Router 250 so a different channel 280 can be selected. Rerouting back to the Routing module 250 or releasing of a payment from the hold queue will cause the bi-lateral and channel totals to be automatically updated as appropriate. 0 The flow control limits for each of the channels and the clearing member banks are stored in a table. These limits are keyed both with respect to the clearing member bank to which payment instructions are sent, and by the clearing channel. The table contains the agreed upon balance limits, the current balance, the number of payments held due to the 5 limit checks, and the maximum value of individual payments allowed.

These limits can be manually updated in a rapid fashion if a contingency situation arises.

A function exists which allows the manual adjustment of the flow control balance for a clearing channel. This is important to take into o account any non-clearing related movements across the external clearing accounts, for example liquidity movements or start of day RTGS balances. The flow control processing has a number of generic defaults which apply in new situations where limits have not previously been set by the operators. For example where a new bank joins a clearing, if an 5 operator has not previously defined a limit for that bank then some default processing will apply to control payments for that bank with a limit forcing all payments to be held.

Once the proposed payment has passed the flow control processing 255, it is passed on to the Product Generation module 275. In o Product Generation 275, the actual message which is transmitted to the channels 280 for clearing is generated. The format of the messages which are generated, will differ depending on which channel 280 is used. Upon reaching a defined stage of processing, the channel 280 will return an acknowledgment 285 which is used to update the hub's 120 records as appropriate. Other products may be generated in Product Generation 275 such as advices to various parties to the transaction.

A contingency function is provided to capture payments that have either been rejected at the clearing bank or encountered in an error at some stage of the payment flow out to the clearing bank. If such is the case, the rejected or errored payments can be manually set back to payment repair (step 225) or back to the Payment Router 250 (see step 300 in Fig.

6).

Figures 6-8 illustrate the processing of the Payment Router 250 of the presentinvention. The processing starts at step 300 with an initialization process 305 in which technical preparatory work is performed.

In step 310, the record for the proposed transaction is read. As previously described, the message from the customers of the hub 120 will contain at least an identification of the payor, payee and the amount of the payment. Additionally, the transaction record may contain an identification of a clearing channel which is preferred by the customer 160. If the customer does not identify a preferred channel of clearance, this field will contain the payment type CLG. In step 325, it is determined whether or not a clearing channel has yet been identified. As previously described, this channel can be identified by the customer, or alternatively can be manually entered by the operators of the hub 120. If the payment type is set to CLG, the router is free to automatically determine the appropriate channel for routing as illustrated in Figures 7 and 8. During this subsequent routing decision process, the payment type will change to EAF, EBA, etc. once the appropriate route has been decided. If the routing has already been determined (payment type is not CLG), the process moves to step 330. Examples of payments for which routing has already been decided (i.e., the specific channel has been defined) are: liquidity payments; payments for which the customer 160 has specified the exact clearing channel to be used; or payments for which the operators of the hub have manually input the channel. Although these types of payments do not require a decision making process for the type of channel to be used, these payments will still be forwarded to the flow control process before the payment is actually released to the channel. Step 330 initiates the process of deciding if the specified channel is available.

In step 335, it is determined whether or not the channel is available for use at all. In the preferred embodiment of the present invention, a channel table is maintained which contains the status of all of the channels to which the hub 120 is connected. An example of such a clearing channel table is in contained in Figure 10. If the channel is not available as determined by the status field contained in the clearing channel table, the process continues at step 365 described below. If the channel is available, it is then decided at step 340 whether or not the particular channel is on holiday. As some of the institutions which maintain the channels recognize national holidays which are not universal, a channel could be on a different holiday schedule than observed by the hub 120. The holiday schedule for each channel is maintained in the clearing channel table (Fig. 10). If the channel is on holiday, the processing will continue in step 365. If the channel is not on holiday, it is determined whether or not the cut off time for the channel has been reached for the type of payment (for some channels different cut off times apply for MtlOO and Mt202 payments). The cut-off time is the last time of day at which a channel will except a payment for processing. The cut-off time details are contained in the channel table illustrated in Figure 10. If the cut-off time has already passed, processing continues in step 365. If there is sufficient time to pass the payment on to the channel, the process continues in step 350. Step 350 has been included in this Figure to indicate that additional checks may be made with respect to the channel availability such as the current debit position. 5 If the channel availability tests 335-350 are all satisfied, it is determined in step 355 if there are any other special formatting requirements. The payment transaction is sent to the flow control processing in step 360 (see step 255 in Fig. 5).

If the processing has reached step 365, it is because the 0 requested or designated channel is not available for use. In step 365 it is determined whether or not the payment is a liquidity payment i.e., a payment initiated by the hub 120 solely for the purposes of moving funds from one channel to another - moving the liquidity.

If the payment is a liquidity payment, the channel can not be 5 changed because of the nature of the payment as described above (step

370). If such is the case, the payment is sent back to payment repair in step 375 (see Fig. 5).

If the payment whose channel is unavailable is not a liquidity payment (NO out of step 365) it is determined whether or not there is any o information contained in the payment transaction record which identifies the type of channel which should be used (e.g., use RTGS, but the specific RTGS channel is not identified). If such information does exist in the payment transaction record, the channel type is set to the appropriate type (e.g., RTGS)(step 390). Note that /NETT/ is a generic coding used in the 5 system to identify a request for a non RTGS clearing channel, while

/RTGS/ identifies a request for an RTGS channel. If no such channel details exists in the transaction record, the channel type is set depending on the payment type of the instruction. The payment type will indicate the channel which was originally chosen. If this is of type RTGS, channel type 0 will be set to /RTGS/. If it is of non RTGS type, channel type will be set to /NETT/. The channel type is retrieved from the channel table contained in Figure 10.

Once the channel type has been set, the payment type is set to CLG (step 395) and the payment transaction is sent on to the process for determining the particular channel as illustrated in Figure 7.

Step 400 in Figure 7 is the initiation of the routing process when no specific route has been identified (step 327 in Fig. 6) or when the request for a specified channel could not be satisfied (step 397 in Fig. 6). In step 405 a list of available clearing channels is retrieved using the clearing channel tables depicted in Figures 9 and 10. If the transaction specifies that the payment should be processed through an RTGS or a non RTGS channel, any non-RTGS or RTGS clearing channels respectively should be excluded from this list.

In step 410 it is determined whether or not a destination clearing bank is directly connected to any of the same clearing systems as the hub 120. If clearing channel returned is TGT (TARGET) or COR (correspondent), there is no such mutual direct connection.

If in step 410 it is determined that there is a mutual direct connection, in step 415 it is determined whether there is more than one. This determination is made using the clearing channel options determined in 405. The CMD table depicted in Figure 9 allows for the maintenance of channel membership by pay- bank. Each pay-bank/channel combination is held in a different record in the table. This structure allows for easier prioritizing of channels when a pay-bank is a member of more than one clearing system. The pay-bank/ channel information can either be manually maintained or an electronic batch process may capture the channel membership details. In order to limit the complexity of the router and other parts of the system, and to have a common interface to the pay- bank/channel details, it is preferred that all channel member details are contained in a single table and each of the channel details conform to the same standard record format. This means for example that German clearing information, which normally identifies banks with a local German BLZ code is not used. Instead, the universal Society for World-Wide Interbank Financial Telecommunications (SWIFT) code is used to identify banks. As illustrated in Figure 9, the CMD table also contains details relating to the preferred routing method. If a pay-bank and the hub 120 have more than one mutual direct connection, the priority is indicated in the CMD table but only if this differs from the default priority as held on the ECC table illustrated in Figure 10. If the pay-bank and the hub 120 do not have a mutual direct connection, TGT (TARGET) and/or COR

(correspondent) may be loaded on the ECC table with priority set where necessary.

Returning to Figure 7, if the pay-bank is not a member of more than one clearing system (step 415) a validation is performed in order to verify that that channel can be used (step 420). As previously described with respect to steps 335-350 in Figure 6, such validation can include determining if the channel is on holiday or if the cut-off time for that channel has been reached. Again, this validation process employs the clearing channel table as depicted in Figure 10. If it is determined that the channel cannot be used (NO out of step 425) the proposed transaction is sent to repair for manual determination of how to process the transaction as previously described. If the channel can be used, the payment type in the transaction record is set to the specified channel in step 435.

Returning to the NO path out of step 410, this path is followed if either the TARGET system or a correspondent is to be used as the clearing channel. In step 440, it is determined whether it is the TARGET system or a correspondent which is to be used. If a correspondent is to be used, the payment type is set to CPO and the correspondent details are read from the clearing channel table (Fig. 10). In step 445, the record for the correspondent in the clearing channel table is read which contains the SWIFT addressed for the correspondent which will enable routing of the payment transaction.

In step 450, the process determines if there are any specific formatting requirements for the channel which has been specified by the 5 routing process, and the payment transaction is forwarded to the flow control process in step 455 (see Fig. 5).

If it is determined in step 440 that the TARGET system is to be used, the list of available clearing channels obtained in step 405 is narrowed to only included the RTGS clearings. This narrowed list is then o prioritized according to default priorities. Similarly, in step 465, if a pay- bank is a member of more than one clearing system (YES out of step 415) the available clearing systems to which the pay-bank is a member are prioritized. However, in the instance the pay-bank override priority from the CMD table (Figure 9) will be used if it is present. In either of these 5 cases, the list of available prioritized channels is passed to the process (Fig.

8) for deciding the channel which is to be used to transfer the funds in step 470.

Information on priority of payment channel is maintained manually. A default priority will be entered on the ECC table (Figure 10). 0 If an override priority is to apply for a pay-bank this is entered on the CMD table (Figure 9).

In step 500 of Figure 8, the prioritized list of channels which can be used to route the payment is provided to the channel decision process. In step 505, the priority will be changed if required by 5 circumstances at the time the final decision is being made. For example, certain payment channels require a minimum volume of payments to be submitted as held on the ECC table (Figure 10). These "priority changes" are automated.

In step 510, it is determined whether all of the channels in the o list have been processed. If not, a decision making process is performed in steps 515-530. The decision making process 515-530 is the same as discussed above with respect to step 420 in Figure 7 and steps 335-350 in Figure 6. If a channel passes all the rules and can therefore be used, the payment type is set to the specified channel and any special formatting required for that channel is identified in step 535. The payment transaction is then sent to the flow control process in step 540.

If all of the available channels have been processed and none of them, for one reason or another, is available for use (YES out of step 510) an error is generated as no channel can be used (step 545). If such is the case, the payment transaction is sent to repair for manual determination of the appropriate channel to use in routing the transaction (step 550). Supporting this invention there are a number of generic "housekeeping" processes which will run on periodic bases to ensure the smooth operation.- These are not defined specifically, but include a nightly reset of Flow Control balances to zero and a cleardown of historical data from the Flow Control Process.

Although the present invention has been described in relation to particular embodiments thereof, many other variations and other uses will be apparent to those skilled in the art. It is preferred, therefore, that the present invention be limited not by the specific disclosure herein, but only by the gist and scope of the disclosure.

Claims

WHAT IS CLAIMED IS;

1. A method of processing payment transactions by a financial institution having a plurality of branches, each payment transaction having a destination bank and each payment transaction being capable of being forwarded through a plurality of clearing systems, the method comprising the steps of: transmitting the payment transactions from the plurality of branches to a central location within the financial institution; determining, for each payment transaction, an appropriate clearing system which to forward the payment transaction; and forwarding each payment transaction to the determined appropriate clearing system.

2. The method as recited in claim 1, further comprising the step of designating a preferred clearing system for one of the payment transactions, and wherein the step of determining the appropriate clearing system considers the preferred clearing system.

3. The method as recited in claim 2, further comprising the step of determining if the preferred clearing system is available for use.

4. The method as recited in claim 2, further comprising the step of determining if the preferred clearing system is on holiday.

5. The method as recited in claim 2, further comprising the step of determining if a cutoff time for using the preferred clearing system has passed.

6. The method as recited in claim 1, wherein the plurality of clearing systems include Real Time Gross Settlement (RTGS) clearing systems, and Multi-Lateral Net Settlement (MLNS) clearing systems, and wherein the RTGS clearing systems can further use a Trans-European Automated Real-Time Gross settlement Express Transfer (TARGET) clearing system.

7. The method as recited in claim 1, wherein the step of determining the appropriate clearing system further comprises the step of deteπnining if the step of forwarding the payment transaction would exceed a predetermined limit.

8. The method as recited in claim 7, wherein the predetermined limit is with set respect to the destination bank.

9. The method as recited in claim 7, wherein the predetermined limit is set with respect to a proposed clearing system being considered for the appropriate clearing system.

10. A method of processing a payment transaction, the payment transaction having a destination bank and the payment transaction being capable of being forwarded through a plurality of clearing systems, the method comprising the steps of: (a) identifying candidate clearing systems which could be used to forward the payment transaction to the destination bank; (b) verifying that a first candidate clearing system is available for use; (c) verifying that a processing of the payment transaction does not exceed a predetermined value limit; and (d) forwarding the payment transaction to the first candidate clearing system.

11. The method as recited in claim 10, further comprising the steps of: sequentially repeating steps (b) and (c) for other candidate clearing systems until one of the other candidate clearing systems satisfies the verification steps of (b) and (c); and forwarding the payment transaction to the one other candidate clearing system.

12. The method as recited in claim 11, further comprising the step of manually routing the payment transaction if none of the candidate clearing^s systems satisfy the verification of either steps (b) or (c).

13. The method as recited in claim 10, further comprising the step of prioritizing the candidate clearing systems.

14. The method as recited in claim 13, wherein the step of prioritizing further comprises the step of giving higher priority to a candidate clearing system identified by a customer as a preferred clearing system.

15. The method as recited in claim 10, further comprising the step of determining if the destination bank is a member of more than one clearing system.

16. The method as recited in claim 15, wherein the destination bank is a member of only the first candidate clearing system, the method further comprising the step of manually routing the payment transaction if the verification of either steps (b) or (c) fail.

17. The method as recited in claim 10, wherein the Trans- European Automated Real-Time Gross settlement Express Transfer (TARGET) is designated as a desired clearing system, the method further comprising the step of eliminating candidate clearing systems which are not Real Time Gross Settlement (RTGS) clearing systems.

18. The method as recited in claim 10, wherein the verification of step (b) further comprises the step of determining if the candidate clearing system is operational.

19. The method as recited in claim 10, wherein the verification of step (b) further comprises the step of determining if the candidate clearing system is on holiday.

20. The method as recited in claim 10, wherein the verification of step (b) further comprises the step of determining if a cutoff time for using the candidate clearing system has passed.

21. The method as recited in claim 10, wherein the predetermined value limit is set with respect to the destination bank.

22. The method as recited in claim 22, wherein the predetermined value limit is a limit of debits accepted by the destination bank.

23. The method as recited in claim 10, wherein the predetermined value limit is set with respect to the first candidate clearing system.

24. The method as recited in claim 23, wherein the predetermined value limit is a limit of debits accepted by the first candidate clearing system.

25. A method of processing payment transactions by a financial institution having a plurality of branches, each payment transaction having a destination bank and each payment transaction being capable of being forwarded through a plurality of clearing systems, the method comprising the steps of: transmitting the payment transactions from the plurality of branches to a central location within the financial institution; for each payment transaction, determine an appropriate clearing system which to forward the payment transaction by: (a) identifying, for each payment transaction, candidate clearing systems which could be used to forward the payment transaction to the destination bank, (b) verifying that a first candidate clearing system is available for use, and (c) verifying that a processing of the payment transaction does not exceed a predetermined value limit; and forwarding each payment transaction to the determined appropriate clearing system.