WO2001098957A2

WO2001098957A2 - Financial transaction processing method and system

Info

Publication number: WO2001098957A2
Application number: PCT/GB2001/002768
Authority: WO
Inventors: Paul William Ormrod; Willem Overeynder; Marcus Geoffrey Rees Hughes; Andrew Peter Blair
Original assignee: Tapx Limited
Priority date: 2000-06-21
Filing date: 2001-06-21
Publication date: 2001-12-27
Also published as: AU2001274312A1

Description

Financial Transaction Processing Method and System

Field ofthe Present Invention

The present invention concerns a financial transaction processing method and system. More particularly, though not exclusively, the present invention relates to an automated electronic back office settlement system for integrating financial settlements between buyers and suppliers (purchasers and vendors). The present invention also extends to a method of securely categorising the type of payment assigned to a transaction so as to securely categorise cashflow for a vendor or purchaser.

Background ofthe Present Invention

Many industries require a highly synchronised chain of reliable suppliers, flexible capacity and just-in-time processes that optimise time to market and capital efficiency to stay competitive in global markets.

In the material supply chain, e-procurement initiatives and electronic trade exchanges, often using the Internet, are currently used to achieve this goal through increased connectivity, collaboration and control between the industry's buyers and suppliers. This translates into faster and cheaper order management, lower inventory levels (reducing material and purchase administration costs) and improved prices.

Referring to. Figure 1, the way in which buyers and suppliers are connected by these e- procurement initiatives and electronic trade exchanges is illustrated. It is estimated that $4 trillion of trade would be possible with global connectivity (source Gartner Group). However, as can also be seen in Figure 1, there is a significant problem in that the back office mechanisms that are required to complete the transaction are disconnected. The same level of cross-enterprise integration, or collaborative business, does not exist between Buyers and Suppliers in the financial supply chain of the B2B (business to business) back-office as does with e-procurement. The key disconnects are in the areas of settlement and financing. More particularly, for settlement procedures, while the procurement-cycle is being integrated via e-trade exchanges, the complimentary payables-to-receivables process is still fragmented, largely paper based and expensive. For financing, the settlement process disconnects mean that the visibility of accurate forward cashflow is poor and costly to manage. This in turn has the. effect of driving up the cost and risk of working capital financing.

It is estimated that the cost of this disconnect problem represents between 2% to 6% of final product cost, in terms of duplicated and fragmented administration, trade finance costs and credit risk premiums. These costs affect both buyers and suppliers.

Considering the disconnect problem in greater detail, Figure 2 shows the different financial processes present in each of the buyer's and supplier's businesses together with the buyer's and supplier's banks. Each of these functions is either implemented or used in order to carry out and complete (settle) a transaction. As has been mentioned before, much of this process is paper-based and there is no automated interaction between the buyer and supplier's banks and these different financial processes based on the transaction itself.

The extent of automation and integration of payments into the transaction cycle to date is shown in Figure 3. Here it can. be seen that the solution only addresses the integration ofthe payables and the payment connection on the buyer's side without any impact on the other mechanisms which are required to complete the transaction. In particular, there is no interaction with the buyer and supplier banks apart from the generation and transmission of a payment instruction to the buyer's bank. Accordingly, this solution provides very little benefit over the totally disconnected situation and does not overcome the back office disconnect problem.

There is another problem with existing systems that is illustrated in Figure 4 in relation to a really big purchaser (RBP) 10. Here a pyramid of outsourcing to supply the needs of the RBP 10 and to reduce overall costs is shown. For example, a car manufacturer (RBP) may outsource the manufacture of engines, brake systems and car seats to reduce costs. Similarly, the suppliers of the outsourced materials may themselves outsource, in this example, the manufacturers of the engines, brake systems and seats also outsource the manufacture of some other components of the products they make, for example the engine manufacturer outsourcing the fuel injection system to a specialist company, and so on. This creates a pyramid 12 of outsourcing which has within it a number of transaction points 14 for each outsourced supplier. The number of transaction points 14 is increased by the supply of materials just in time (JIT) to meet given deadlines. The cost of financing trade credit accumulates at each of these transaction points 14 within the pyramid 12.

The problem with this typical structure is that there is an increasing lack of visibility of payment information as one moves down the pyramid 12. This in turn causes increases in financing costs and risk premiums as the credit available to typically smaller and smaller purchasers becomes more and more expensive. This problem has been termed the liquidity disconnect.

Currently, the total settlement costs together with liquidity costs account for around 2% to 6% of the total product costs of businesses as has been mentioned earlier. It is predicted that as more and more industries drive down material input costs by using outsourcing and e-business procurement methods, this percentage will rise thereby creating an even greater problem.

Summary ofthe Present Invention

It is an aim of the present invention to overcome or at least substantially reduce the back office disconnect problem described previously. It is a further aim ofthe present invention to overcome or at least substantially reduce the liquidity disconnect problem described previously.

It has generally been appreciated by the present inventors that current industrial B2B markets currently lack settlement mechanisms of similar efficiency and reliability to those in Financial Securities markets. The inventors have appreciated that the solution to the above described settlement disconnect problem lies in providing a settlement system that has the characteristics of being assured and tightly integrated with the procurement cycle.

According to one aspect of the present invention there is provided a back office settlement system for settling the finances of a transaction, the system comprising: input means configured to be responsive to input signals created in response to transaction events that occur throughout a purchasing transaction from order through to invoice; and an update engine operatively connectable to a vendor's bank and a purchaser's bank for updating the current balance of, and future cash positions of both the vendor's and purchaser's bank accounts with payment schedule data corresponding to the transaction events.

The single transactional entry thus effectively gives rise to a double accounting entry in the vendor/purchaser bank accounts, creating a single accounting source for the transaction and thus eliminating the need for the duplicate processing that buyers and suppliers currently need to manage for each transaction in their respective systems (i.e. accounts payable is but the mirror image of accounts receivable).

The present invention brings the settlement cycle in B2B markets up to the level of integration with the procurement cycle that is comparable with Securities Markets. It significantly reduces the costs of both settlement and trade finance and, therefore improves liquidity and product costs across whole supply chains.

A preferred embodiment of the present invention, hereinafter referred to as the tapX system (the assured payment eXchange), brings the missing settlement link to Really Big Purchasers (RBP) and trade-exchanges to release the full value of e-B2B.

Referring now to Figure 5, the way in which the present invention integrates the back office settlement system is illustrated. As can be seen, with links to both the vendor's and purchaser's banks as well as the e-procurement and e-supply engines it is possible for the present invention to integrate the entire back office settlement procedure. Comparison of this figure with Figures 2 and 3 clearly illustrates the difference between the present invention and the prior art. The present invention provides integration ofthe settlement cycle with the order cycle. This allows buyers to leverage their credit ratings to drive down the cost of financing working capital across their supplier base. Figure 6 shows the liquidity, which is generated by the present invention and the different stages in the procurement cycle where financing can be provided. This is only possible because of the visibility that the present invention provides in terms of enabling forward cashflow forecasts to be generated.

Furthermore, the integration of the order cycle with the end-to-end settlement (payables and receivables) eliminates duplicate administration and provides accurate visibility of payment information. These factors drive out processing and working capital costs across the value chain. This is shown in a comparative fashion in Figure 7 which is a graph ofthe scope of integration verses the beneficiaries. The comparison is carried out with respect to electronic bill presentment & payment (EBPP) solutions and card based payments. As can be clearly seen, the present invention provides the greatest level integration and also the greater number of beneficiaries.

The present invention embodied in tapX operates a fully integrated settlement service for buyers and their suppliers and manages information on their payment liabilities throughout the procurement cycle, making relevant information on payment status available to both parties and their respective banks, so that they can make appropriate treasury management decisions to cover their liabilities.

The tapX embodiment therefore provides an infomediary service by bringing together in a secure environment the otherwise disconnected settlement information of corresponding trading parties, and managing all their settlement administration in terms of payment execution, receipt and reconciliation in a single, seamless process that centralises all control and audit trails.

The key benefits for buyers and suppliers are the elimination of duplicate accounting administration and control associated with accounts payable (AP) and accounts receivable (AR) and cash & bank reconciliation, improved treasury management (cash, bank and short term financing) and reduced costs of trade financing across entire value chains.

For banks, the benefits include access to an increased market for trade finance / treasury services and enhanced risk management information to support corporate lending decisions.

Preferably the update means is arranged to implement the updating procedure simultaneously. This gives the added advantage that at any moment in time the balances at the vendor and purchaser's bank accounts are consistent and reliable and can be used to make accurate decisions on future cashflow positions.

The updating means is preferably arranged to carry out the above updating automatically, without user interaction once it has been set up, by taking input directly from the buyer's transactions processing systems. This can advantageously enable the process ofthe transaction from initial order to delivery and final payment for goods to be accurately monitored.

The system can preferably support transactions that involve buyers and suppliers with accounts in separate banks (i.e. multi-bank). It can also preferably support purchase transactions made in different currencies (multi-currency).

The present invention can also be considered to be a method of settling the finances of a transaction, the method comprising: creating input signals representing transaction events that occur throughout a purchasing transaction from order through to invoice; inputting the input signals into a back office settlement system; connecting the back office settlement system to a vendor's bank and a purchaser's bank; and updating the current balance of, and future cash positions of both the vendor's and purchaser's bank accounts with payment schedule data corresponding to the transaction events.

The present invention in one of its broadest aspects relates to a back office assured payment system which is configured to be responsive to an input signal, created in response to a transaction event, to update (credit and debit) automatically both a vendor's and a purchaser's bank accounts with data corresponding to that transaction event.

The present invention may also be considered according to another aspect to be a method of effecting an electronic transaction between a vendor and a purchaser, the method comprising: receiving event data relating to the transaction including purchase order details of the transaction; and carrying out electronic scheduling and execution of payments to and from bank accounts ofthe purchaser and the vendor in accordance with the value of the transaction and in correspondence with the acceptable supply of goods or services that are the subject ofthe transaction.

The above described broad aspects of the system form a backbone upon which all additional benefits and services of purchase data tracking, future cashflow projections and guaranteed credit at given dates can preferably be based.

The management information generated by the present invention enables many different functions to be performed. For example the following functions are supported by tapX: Treasury management functions with information on forward cash positions;

Credit risk management by buyer's and supplier's host banks;

Trade finance administration;

System administration of interfaces;

Control of user access; Support AP/AR accounting (including fiscal audit trails), through direct feeds to buyers' and suppliers' accounting systems and tapX reporting tools; and tapX subscriber accounting statement services.

The settlement cycle is preferably driven by input from the purchaser. This means that the system can take on a purchaser's new suppliers with maximum speed and flexibility, thereby avoiding lengthy and costly systems integration which would have been required supplier by supplier. According to another aspect of the present invention, there is provided a back office connect system for completing financial settlement of a transaction between a purchaser and a vendor, the system comprising: input means arranged to receive data relating to the transaction; reading means having access to the purchaser's bank account, the reading means being arranged to read the available balance in the account and a credit facility assigned to that transaction by the purchaser's bank; and categorisation means arranged to provide a secure categorisation of the type of payment that relates to the transaction according to the read information, such that a secure categorisation of future cashflow ofthe vendor can be determined.

The provision of knowledge of the quality of a vendor's cashflow can greatly assist in that vendor's own purchasing power as a buyer and in lowering its cost of working capital, for example, by the amount and type of credit that subsequently becomes available to that vendor.

The tapX embodiment of the present invention describes ways in which the above- described different aspects of the present invention can be implemented. The benefits of these to the buyers include providing simpler, cheaper admin (payables, payment processing, bank reconciliation), enabling flexibility to negotiate credit terms, even in new or transient relationships and giving potential to leverage assured payment status to improve supplier terms.

Similarly, the supplier also benefits by having simpler, cheaper administration (receivables, receipt processing, bank reconciliation), qualifying for minimum credit risk, having the flexibility to offer credit terms, even in new or transient relationships and by having access to faster and cheaper trade finance.

The e-trade exchanges also benefit by being able to offer an enhanced range of services to buyers and suppliers and hence generating the opportunity to increase membership base, market share and liquidity. Finally, the banks even benefit by having an opportunity to increase volume of trade finance services.

By being able to categorise the types of payments to be made, the tapX embodiment can report the level of assurance behind payments in terms of the documentary status of an order (e.g. confirmed purchase order verses goods received note verses invoice), as reported by the purchaser, and the quality of financial backing that the purchaser deems is necessary to effect the purchase (either committed funds or corporate covenant backed credit).

The tapX embodiment provides trading partners that subscribe to its service with the means to cascade rapidly the leverage of the assured payment status of a RBP across all tiers of the supply chain. In this regard the existing difficulties described previously in Figure 4 can be substantially reduced.

The tapX embodiment provides, therefore, tier 1 suppliers and their banks with a secure mechanism to convert rapidly the assured payment status of their purchasers into trade finance, via invoice discounting and to use that finance to assure the payment of their own purchases from tier 2 suppliers. Similarly, these tier 2 suppliers and their banks are able to use their tapX accounts to themselves obtain trade finance for their purchases from tier 3 suppliers and so on.

Similarly, RBPs will in some instances be suppliers as they dispose of surplus assets or stock. The tapX embodiment therefore supports all subscribers, whether operating in any given transaction as buyer or supplier, to seamlessly view their consolidated treasury position in terms of actual cash, assured payments in, bank credit lines and assured payments out and arrange for appropriate short term treasury coverage.

Operating units within the tapX embodiment are each typically set up to support either a single RBP or a major vertical market trade-exchange. Given that many suppliers service multiple RBPs, sometimes in multiple vertical markets, tapX provides a consolidating mechanism that provides company treasurers the ability to view their treasury and short-term financing positions at the appropriate level of consolidation. Companies are able to access this information through unique and secure sets of identifiers.

Alternatively, this aspect of the present invention may be considered as a method of completing financial settlement of a transaction between a purchaser and a vendor, the method comprising: receiving data relating to the transaction; accessing the purchaser's bank account and reading the available balance in the account and credit facilities assigned to that transaction by the purchaser's bank; and providing a secure categorisation of the type of payment that relates to the transaction according to the read information, such that a secure categorisation of future cashflow of the vendor can be determined.

According to another aspect of the present invention there is provided a method of repaying a loan to a borrower that is tied against future receivable funds, the method comprising: setting up a receivable specific finance account; re-routing a receivable funds payment path from an account ofthe borrower to the receivable specific finance account; and automatically repaying the loan on receipt ofthe receivable funds via the re-routed payment path to the receivable specific finance account.

This method removes the risk that the supplier applies the received funds for any other purpose than repaying the loan or is unable to remit them to the lender for any reason. Advantageously, no additional exposure is taken to the supplier in respect of either credit or country risk. Both of these features enable the risk of making a loan far less thereby improving the possibility of securing such loans.

This aspect of the present invention may also be considered as an apparatus for repaying a loan to a borrower that is tied against future receivable funds, the apparatus comprising: a receivable specific finance account; means for re-routing a receivable funds payment path from an account ofthe borrower to the receivable specific finance account; and means for automatically repaying the loan on receipt of the receivable funds via the re-routed payment path to the receivable specific finance account. According to another aspect of the present invention there is provided a method of providing and repaying a securitised loan to a borrower that is tied against future receivable funds, the method comprising: setting up a receivable specific finance account and a securitisation account of a lender; providing a securitisation loan from 5 the securitisation account of the lender to the receivable specific finance account for payment to the borrower; re-routing a receivable funds payment path from an account of the borrower to the securitisation account via the receivable specific finance account; and automatically repaying the loan on receipt ofthe receivable funds via the re-routed payment path to the securitisation account via the receivable specific finance 10 account.

This way of securitising the loan significantly reduces the risk to the securitisation entity making the investment in securitised loans considerably more attractive since there is no direct credit or country risk exposure to the supplier. This lowering of risk 15 enables a securitisation of the loan to become a much more viable and attractive prospect.

The above described method may further comprise attaching details of the securitisation loan to entries at the receivable specific account such that the repayment 20 step causes repayment of the securitisation loan to the securisationsecuritisation account ofthe lender.

By attaching securitisation details to entries in the receivable specific account as applicable, it is possible for a programme manager to see full details ofthe securitised 25 loans and underlying receivables by programme with no duplication of data. Additionally, by providing all parties involved with different views of the same data considerable reductions in the cost of administration involved in a securitisation program can be obtained.

30. This aspect of the present invention may also be considered to be an apparatus for providing and repaying a securitised loan to a borrower that is tied against future receivable funds, the apparatus comprising: a receivable specific finance account; a securitisation account of a lender; transfer means for providing a securitisation loan from the securitisation account ofthe lender to the receivable specific finance account for payment to the borrower; re-routing means for re-routing a receivable funds payment path from an account of the borrower to the securitisation account via the receivable specific finance account; and repayment means for automatically repaying the loan on receipt of the receivable funds via the re-routed payment path to the securitisation account via the receivable specific finance account.

According to another aspect of the present invention there is provided a method of transferring funds between a purchaser and a vendor as part of a purchasing transaction therebetween, the method comprising: creating a first nostro account for the vendor's bank at the purchaser's bank and a second nostro account for the purchaser's bank at the vendor's bank; receiving input signals from a purchaser, the signals relating to at least one transaction event that occurs during the purchasing transaction and, in response thereto, instructing a fund transfer at both the purchaser's bank and the vendor's bank; and transferring funds internally within the purchaser's and vendor's banks from a purchaser's bank account to the vendor's bank's nostro account at the purchaser's bank and from the purchaser's bank's nostro account to a vendor's bank account at the vendor's bank, in response to the instructing step.

In this way, payments to the suppliers' accounts can be routed without any clerical intervention on the part of the bank, which in turn reduces bank cost and the risk of a bank error. Furthermore, it is also possible to eliminate the bank's clerical effort with regard to inter-bank settlement.

Alternatively, this aspect of the present invention may be considered as a system for transferring funds between a purchaser and a vendor as part of a purchasing transaction therebetween, the system comprising: at a purchaser's bank, a first nostro account for a vendor's bank and a bank account for the purchaser; at the vendor's bank, a second nostro account for the purchaser's bank and a bank account for the vendor; a back office connect engine for receiving input signals from a purchaser, the signals relating to at least one transaction event that occurs during the purchasing transaction; and bank driver means responsive to the back office connect engine, for instructing an internal fund transfer at each of the purchaser's bank and the vendor's bank; the bank driver means being arranged for each transaction to generate instructions for two equivalent value fund transfers from the purchaser's bank account to the vendor's bank's nostro account at the purchaser's bank and from the purchaser's bank's nostro account to the vendor's bank account at the vendor's bank.

Brief Description ofthe Drawings

Presently preferred embodiments ofthe present invention are now described by way of example with reference to the accompanying drawings. In the drawings:

Figure 1 is a schematic diagram illustrating the back office disconnect problem between purchasers and suppliers with the prior art;

Figure 2 is a schematic block diagram further illustrating the back^* office disconnect problem with reference to the purchaser's and vendor's banks;

Figure 3 is a schematic block diagram showing the back office disconnect problem shown in Figure 2 but further showing recently proposed solutions to improve the back office disconnect problem;

Figure 4 is a schematic diagram illustrating a problem with existing ways of outsourcing and its trade financing;

Figure 5 is a schematic block diagram showing the back office functions of Figures 2 and 3 but further showing how an embodiment of the present invention integrates these functions to overcome the back office disconnect problem;

Figure 6 is a schematic diagram showing how in an embodiment of the present invention, the different functions of a settlement cycle are integrated with the various stages of an existing procurement cycle;

Figure 7 is a comparative performance chart showing how an embodiment of the present invention performs in comparison to existing settlement procedures; Figure 8 is a schematic block diagram showing a back office settlement system of a presently preferred embodiment of the present invention in relation to buyers and suppliers and their respective banks;

Figure 9 is a more detailed block diagram of the back office settlement system shown in Figure 8;

Figure 10 is a detailed block diagram showing the architectural structure of the tapX back office settlement system of Figure 9;

Figure 11 is a schematic block diagram showing in general terms the basic process which occurs in the tapX back office system of Figure 9;

Figure 12 is a detailed flow diagram showing the processes that occur throughout the back office settlement system at the buyers, suppliers, their banks and at the tapX system;

Figure 13 is a schematic flow diagram showing the processes involved in the tapX engine handling secure receivables financing;

Figure 14 is a schematic flow diagram showing the processes involved in the tapX engine handling securitisation of financing;

Figure 15 is a schematic block diagram showing bank connection between the tapX engine and the supplier's and buyer's banks according to a second embodiment of the present invention;

Figure 16 is an exemplary graph showing forecast inflows for a supplier;

Figure 17 is an exemplary graph showing forecast outflows for a supplier; and

Figure 18 is an exemplary graph showing cumulative cashflow forecasts based on the graphs of figures 16 and 17 for a supplier.

Detailed Description of Preferred Embodiments

A presently preferred embodiment of the present invention, hereinafter referred to as the tapX system, is now described with reference to Figure 8. The system 30 is shown schematically in Figure 8 as comprising a set of buyers 32, a set of those buyers' banks 34, a set of suppliers 36, a set of those suppliers' banks 38 and a back office settlement engine 40 (tapX engine). Each of the buyers 32 is connected indirectly to their corresponding banks 34 (see links 42) and similarly, each of the suppliers 36 is connected indirectly to their bank accounts 38 (see links 44). Each of the buyers 32, suppliers 36 and banks 34, 38 also have access via communication links 46 to the tapX engine 40, which acts as a communication centre for essentially monitoring an procurement cycle between a buyer 32 and a supplier 36 and accordingly driving a settlement cycle between the buyer's bank 34 and the supplier's bank 38. Accessibility to the tapX engine 40 by the suppliers 36 and buyers 32 enables the payment status of each transaction to be monitored and for further benefits regarding cashflow projections to be obtained.

The tapX system 30 is now described in greater detail with reference to Figure 9, which shows the explicit connectivity between the above described elements of the system 30. Each of the buyers 32 and suppliers 36 have an electronic Accounts/Reconciliation system 48, which is used for accounting purposes including keeping track of orders and their respective payments. These systems 48 are well known in general and can be of different standards. However, the systems 48 used by the buyers 32 have an additional capability of communicating directly with the tapX engine 40.

Each of the buyers 32 is connected to the tapX engine 40 in two ways. Firstly, via a direct buyer connection 50 between the electronic Accounts/Reconciliation system 48 and the tapX engine 40, and secondly via the Internet 52. The direct buyer connection 50 is used primarily for sending procurement cycle information to the tapX engine 40. The connection via the Internet 52 is used primarily for buyer observation ofthe status ofthe settlement procedure.

The suppliers 36 are only connected in a single way to the tapX engine 40 via the Internet 52. This is because in the present embodiment, the tapX system 30 is driven by input data from the buyer 32 alone. Accordingly, the suppliers 36 also have the means to view the current status ofthe settlement cycle. Each ofthe buyers' and suppliers' banks 34, 38 are connected to the tapX engine 40 in two ways. Firstly, each bank 34, 38 has a tapX engine interface 54 which enables a direct bank connection 56 to the tapX engine 40 to be made and secondly, each bank 34, 38 has a connection via the Internet 52. The direct bank connection 56 is used for accessing dedicated current bank accounts of the buyer 32 and supplier 36 and for updating (crediting or debiting) current bank account information held there in accordance with a settlement cycle being carried out. More particularly, these accounts are supplied with forward cash movements associated with key events in the procurement cycle (e.g. order, delivery, invoice). Also on settlement maturity, these direct bank connections 56 are used for direct payment execution and bank reconciliation for both buyers and suppliers. These processes are described in detail later.

The tapX engine 40 manages the execution of all payments, whether domestic or cross-border via established, secure bank messaging systems (e.g. CHAPS). The tapX engine 40 optimises the use of these banking messaging systems by managing the appropriate consolidation/netting of payments.

Referring now to Figure 10, the tapX engine 40 of the present embodiment is shown in detail. The tapX engine 40 comprises four types of different elements which in combination, as shown in Figure 10, perform the settlement procedure mentioned above. These types of element are the Universal Procurement Gateway (UPG) 58, the Global Web Server (GWS) 60, the Universal Bank Gateway (UBG) 62 and the Processing Engine 64. The tapX engine 40 comprises a single GWS 60 which provides Internet connections 52 to suppliers 36, banks 34,38 and 'n' buyers 32 where n is an positive integer. Figure 10 also shows how 'n' RBPs 32 are connected to the GWS 60. For each RBP 32, a set comprising a UPG 58, a Processing Engine 64 and a UBG 62 are provided, such that the tapX engine 40 has 'n' sets with 'n' typically being 256 for example. These elements form a channel for processing information from the corresponding RBP 32. (In an alternative embodiment, each channel may be connected to several different RBPs 32 as the Processing Engine 64 in this alternative embodiment has the capability to handle several channels concurrently.) Each of the above-mentioned different types of elements is now described in detail below. The UPG 58 provides an XML-based gateway whose purpose is to receive data concerning purchase orders, deliveries and invoices from the e-procurement and ERP (Enterprise Resource Planning) systems of the buyers 32 using the tapX system 30. The UPG 58 then validates the data received (carrying out error correction procedures if required), enriches the data received based upon embedded rules (for example by calculating settlement dates based upon credit terms), reformats the data from the fonnat used in the ERP systems of the buyers 32 into an internal data format utilised by the Processing Engine 64 and forwards it to the Processing Engine 64.

The UPG 58 comprises a "Message/File Formatter" (not shown), which takes the XML data from the buyer and maps it into a format suitable for a "Transaction Translator and Validator" (TTN) function (not shown), which is implemented by the Processing Engine 64. The TTN function takes the data for validation and translation purposes at each stage of the procurement cycle and pre-validates the account holder and transaction path. All errors are passed back to the buyer 32 for correction and resubmission.

The Message/File Formatter essentially comprises two software components: a Neon Process Server, which is used to normalise and enrich the incoming message and to do initial validation on the format and a Neon e-Business Integrator, which is used to parse, reformat the data and then route the data based on pre-defined rules. The Message/File Formatter is responsible for the delivery of transactions and standing data to the TTN function and also the collection of error messages/files and echoes from the TTN function back to the buyer 32.

The specific format of the data being sent is determined in a business analysis and . mapping exercise, when the buyer 32 becomes a customer ofthe tapX system 30. For each buyer 32 the format may differ and therefore the Message/File Formatter is able to handle multiple data formats. The output from the message formatter is in a format expected by the TTN function of the Processing Engine 64. More specifically, in the present embodiment the Message/File Formatter requires several essential fields of data in order to handle messages from the buyers' ERP systems, namely messages relating to confirmed purchase orders and to receipt of goods and services. These fields of data are an identifier of the buyer 32, an identifier of the supplier, the date when the goods have been received or on which payment is due, the amount of the transaction, and the purchase order number. Other fields may also be provided such as an invoice number or currency type, for example.

The data field holding the date on which payment is due can be substituted by the buyer 32 with data describing the date of the invoice and the settlement terms (from which the settlement period can be calculated). This calculation is termed enhancement of the received data. If the essential data, or other fields for calculating the essential data, are not present then the UPG 58 can reject the incoming data as being incomplete .

The Process Server breaks down the ERP purchase order message/file into line items and enriches the data for use by the rest of the Processing Engine's functions. Each raw purchase order line item undergoes some mapping in order to add the correct transaction type/posting rule for the generated tapX transaction. The enrichment may also use standing data regarding the buyer or supplier which has previously been communicated to the Processing Engine 64 and is stored therein. The UPG 58 retains a copy of the enriched line items in the Processing Engine database (not shown) for future reference or reconstructing the data for the buyer 32. The Process Server determines if the message sent is an add, modify or delete message based on the data held on the line item.

The reformatting of the data from one format to another which is carried out by both the UPGs 58 and the UBGs 62, is a standard procedure which relies on predetermined knowledge ofthe formats between which the conversion is to take place. Accordingly this is not described in any further detail herein.

Additionally, any transactions or data initiated through the GWS 60 are routed through the UPG 58 and the above described processes are applied to them.

The primary purpose of the GWS 60 is to provide all users of the tapX system 30 (buyers 32, suppliers 36, banks 34, 38) with views of data relating to the transactions handled by the tapX system 30 through internet browsers. Some examples of the data that can be supplied are described later with reference to Figures 16, 17 and 18. This data is extracted from a database 66 that mirrors the data (not shown) that is held on the Processing Engine 64.

Additionally, users are able to download files relating to their particular transactions from GWS 60, and certain limited data or transactions can be input via the GWS (and routed through the UPG 58 as explained previously), where such information is not available from the buyers' or banks' systems.

It is to be appreciated that for Internet access to the tapX engine 40, a website for the tapX engine 40 is provided on the GWS 60 and access to status of any particular transaction's settlement cycle is only accessible by password protected gateways. Information is passed between the tapX engine 40 and any of the buyers 32, suppliers 36 or banks 34, 38 in a standard http format which is well known and need not be described herein.

• The purpose ofthe UBG 62 is to act as a communications interface, between each Processing Engine 64 and the electronic funds transfer systems and balance and transaction reporting systems (not shown) ofthe banks 34, 38. This entails the UBG 62 reformatting bank transfer instructions generated within the Processing Engine 64 into a predetermined format required by the remitting bank. Also the UBG 62 is arranged to reformat transaction and balance data received from various banks' systems into the standard format mentioned above, which is utilised by the Processing Engine 64.

The Processing Engine 64 receives transaction data from both the UPG 58 and the UBG 62 and carries out the following tasks: a) re-presents bank statements to show enriched information concerning cleared items; b) adds data concerning future cash movements to bank statements; c) generates bank transfer instructions; d) reconciles transaction data received from both the remitting and receiving banks to the bank transfers it has instructed; e) manages the reservation of cash deposits and credit lines on a buyer's bank account against specific orders / invoices; f) manages the transaction flows and interest charges relating to receivables finance loans; and g) manages the transaction flows and asset accounting relating to the securitisation of receivables finance loans.

These tasks are all implemented in software as the Processing Engines 64 are each essentially a processing device executing software routines for each of the above tasks. Each Processing Engine 64 is a standard commercially available software product from Cashfac Limited called Virtual Banking Technology. This product is a general-purpose parameter-driven software product which can be adapted to different applications. There would be no difficulty in the skilled addressee inputting the required parameters to make this product function as the above described Processing Engine 64 once knowledge ofthe desired functionality ofthe Processing Engine 64 as described herein was known. Accordingly, no further explanation of the detailed workings ofthe Processing Engine 64 is required or provided herein.

As mentioned briefly above, the Processing Engine 64 incorporates a database (not shown) holding details of all these transactions. The database is mirrored in the database 66 of the GWS 60 to provide external users (buyers, suppliers and banks) with access to the data relevant to them. Furthermore, the mirror database 66 provides a back up to the other database (not shown) should there be some data failure, such as corruption of data. The updating ofthe mirror database 66 occurs at regular intervals.

The above described tapX system 30 acts as a platform for the back office connect settlement process as well as many other related processes. In the following the main back office connect settlement process is described together with several other related processes which in themselves solve problems.

Referring now to Figure 11, there is shown an overview of how the tapX engine 40 uses the different stages of a procurement process to interact with the bank accounts of the buyers and suppliers to implement the back office connect settlement process. More specifically, Figure 11 schematically shows the process of how the different stages of a procurement cycle are routed though the tapX engine 40 and are used to drive the settlement cycle with bank interaction.

The tapX engine 40 has access to both the buyer's bank account 100 and the supplier's bank account 102, which enable the current cash position to be determined. Respective virtual extensions 104, 106 of the buyer's and supplier's bank accounts 100,102 are made within the tapX engine 40 to enable a very accurate picture of future cashflows and credit limit usage to be determined for both the buyer 32 and the supplier 36. Also this picture provides both the supplier and buyer with the approval status ofthe procurement cycle and the corresponding settlement cycle.

As mentioned previously, the settlement cycle is driven by input from the buyer 32. This entails details of the different stages of the procurement cycle being sent to the tapX engine 40 from the buyer 32. The placement of an order with a supplier 36 is communicated to the tapX engine 40 and this causes an order entry 108 from the buyer's virtual bank extension 104 to be made in the supplier's virtual bank extension 106. Similarly, when delivery of the goods to the buyer 32 and the subsequent receipt of an invoice are communicated to the tapX engine 40, a delivery entry 110 and an invoice entry 112 are made in the supplier's virtual bank extension 106. Finally, the tapX engine 40 schedules at some future point in time, a payment 114 to be made directly from the Buyer's bank account 100 into the supplier's bank account 102 using a standard messaging system such as CHAPS or SWIFT. In this way, tapX engine 40 sources, schedules and executes payments 114 to provide account holders (buyers 32 and suppliers 36) with an integrated view from confirmed order, of current and forward cash and its source.

The process which has been described in outline above with reference to Figure 11, is now described in detail with reference to Figure 12, which is a summary of the key process flows carried out in the tapX system 30 between the buyers, suppliers and their respective banks. Figure 12 shows that there are six different stages (set out as columns) in the procurement cycle and hence six corresponding stages of the settlement cycle. These are:

1. the setting terms and standing data for both the buyer and supplier stage 120; .

2. the placing the purchase order for the buyer and processing the sales order for the supplier stage 122;

3. the receiving goods and/or services for the buyer and fulfilling orders for the supplier stage 124;

4. the managing purchase invoices for the buyer and raising sales invoices for the supplier stage 126;

5. the paying purchase invoices for the buyer and collecting cash for the supplier stage 128; and 6. the reconciling bank operations for both the buyer and supplier stage 130.

The rows of Figure 12 indicate the party involved, namely the buyer 32, the buyer's bank 34, the tapX engine 40, the supplier's bank 38, and the supplier 36, in the respective part of the settlement cycle. In this embodiment, the buyer 32 has a procurement engine (not shown) and an accounts reconciliation system 48 and the supplier 36 has a supply engine (not shown) together with an accounts system 48.

The procurement and settlement cycles commence with the setting up of terms and standing data stage 120. As part of this, master data is set up at 132 at both the buyer 32 and the supplier 36 in readiness for the procurement cycle. The master data at the buyer 32 includes the supplier's details, information regarding the buyer's inputs and outputs, and the buyer's bank details. The master data at the supplier 36 includes customer details and details regarding the supplier's bank. As the inputs to the tapX engine 40 are buyer driven, the supplier's details provided by the buyer 32 are required to be confirmed by the supplier 36 at the commencement ofthe settlement cycle. The buyer 32 commences by inputting at 134 their bank details, authorisations, supplier details from their procurement engine or general accounting system 48 to the tapX engine 40. These are used by the tapX engine 40 to set up the tapX master data at 136, which essentially involves setting up or updating at 138 the buyer's details and the supplier's details, including their bank details. As mentioned above the data supplied by the buyer 32 regarding the supplier 36 is confirmed by the supplier. Once the tapX master data 136 has been set up, the tapX engine 40 has authorised access to both the buyer's bank account 100 and the supplier's bank account 102.

The second stage in the procurement and settlement cycles is the placing and processing of a purchase order stage 122. This stage is triggered by the buyer 32 creating an authorised purchase order at 142. This is transmitted to the supplier 36 via the procurement and sales engines and the supplier processes and then confirms at 144 the purchase order (sales order). At this point, the supplier's systems may at 146 check stock credit status etc. The confirmation includes a fulfilment schedule. Details 148 of the agreed purchase order, together with details of the fulfilment schedule are transmitted at 150 from the buyer 32 to the tapX engine 40 as this part of the settlement cycle. The tapX engine 40 captures these details at 152 and sets at 154 the payment status to 'purchase order confirmed', namely the payment status on buyer's and supplier's accounts is set to "assured subject to receipt & invoice". Both of these latter events of capturing the confirmed purchase order at 152 and setting the status to 'purchase order confirmed' are respectively monitored at 156 by the buyer 32 and the supplier 36 through the GWS 60 as part of their respective treasury management procedures 158, 160.

The tapX engine 40 also determines the quality of financing which is to be allocated to the transaction. For example, the input from the buyer at 150 has a credit backing flag (not shown) which if set triggers the following procedure in the tapX engine 40. If the credit backing flag is set to "bank assured" (i.e. backed by cash or committed credit line), then the tapX engine checks to see if the purchase order total is less than the available cash in the buyer's bank account plus any credit facility available under a committed credit line. If the purchase order total is less, the credit backing level is set to "bank assured" otherwise it is set to "purchaser assured". If bank assured status is not possible due to insufficient funds, then this is reported at 156 to the buyer 32.

The third stage of the supplier 36 fulfilling the order and the buyer 32 receiving the goods/services at 124 commences with the supplier 36 fulfilling the order at 162. The order is delivered at 164 with receipt of the goods/services being approved at 166. A Goods Received Note (GRN) authorised by the buyer 32 is sent back at 168 to the supplier 36. At the buyer 32, the purchase order is updated at 170 with the GRN data, part deliveries are logged as are returns and the general accounting system (GA) is updated.

This updated information on the purchase order and the delivery is transmitted at 172 to the tapX engine 40. Here the payment status of the transaction is updated at 174 with information relating to the term of the payment, the credit lines associated therewith and the GRN data. The payment status is changed to 'Assured subject to invoice'. This status is then transmitted at 176 to the supplier's treasury management process 160. At this point, the supplier's systems may at 178 update the goods received status and the GA.

The fourth stage of raising and managing sales invoices at 126 commences with the supplier 36 issuing at 180 an invoice for the delivered goods/services. The invoice contains two essential pieces of information, namely the amount ofthe invoice and it payment term which are required by each ofthe supplier's, buyers accounts systems 48 and the tapX engine 40. The issued invoice is supplied at 182 directly to the buyer 32. However, as is illustrated in Figure 12, there is an option for the invoice to be passed through the tapX engine 40 where it can be validated and consolidated with other invoices thereby converting invoices into a standard e-format. (In this embodiment this service can be provided by the tapX engine 40 but alternatively, it can be provided by a separate electronic bill presentation software product.) On receipt ofthe invoice, the buyer 32 approves the supplier invoice at 186 when the purchase order and the goods received invoice have been matched at 188. Also at this point, the GA is updated at 188. It is to be appreciated that in the case of purchases requiring three-way matches (Purchase Order/GRN/Invoice), the buyer 32 is responsible for ensuring appropriate matching. The tapX engine 40 will therefore not update a payment status (described below) where the buyer 32 provides invoice details ahead of GRN details, until it receives explicit buyer confirmation that payment status can be set to "Assured".

These matching actions 188 at the buyer 32 are communicated at 190 to the tapX engine 40, which in turn updates the payment status at 192. In the present case, the payment status is set at 194 to 'Assured' and future payment commitments regarding matched invoices are logged at 196 onto both the buyer's and supplier's bank accounts 100, 102 by value and date. Accordingly, the tapX engine 40 manages the reservation of cash deposits and credit lines on a buyer's bank account against specific orders/invoices. Further the updated payment status is communicated at 198 to the supplier's treasury management process 160.

As an alternative to the above, it is possible for the buyer 32 to raise a self invoice at 200 at the end of the third stage 124 when the goods have been delivered. The self- invoicing step simply comprises the buyer 32 creating at 200 an invoice for the goods/services received. This invoice is then sent at 202 to the supplier 36 and also communicated at 204 to the tapX engine 40 where the payment status is updated at 192 as described above.

At the supplier 36, the buyer's self-invoice is received and registered at 206. The supplier 36 then issues its own supplier invoice for its internal accounting procedures and updates its GA.

The fifth stage 128 of the buyer paying purchase invoices and supplier collecting the payments, commences with the tapX engine determining at 208 payment schedules and funding for the buyer 32 so that they can make a decision on payment approval. More particularly, the tapX engine 40 determines forward funding needs and payment schedules at 210. These are then communicated at 212 to the buyer 32 and also to the buyer treasury management process 158. The buyer 32 then has sufficient information to approve at 208 the payment to the supplier 36, namely to approve the payment schedules ofthe supplier 32.

Approval of the payment schedules by the buyer 32 is communicated at 214 to the tapX engine 40. Then the payment is executed at 216 under the control of the tapX engine 40 at the appropriate time and in accordance with the payment schedule. The execution of a payment involves sending at 218 instructions to the buyer's bank 34, sending at 220 instructions to the supplier's bank 38 and reporting at 222 to the supplier's treasury management process 160. Approval for the payment of money from the buyer's account 100 may already have been provided by the buyer's treasury management process 158 authorising at 224 the payment.

In the sixth stage of reconciling bank operations at 130, completion of the transfer of funds (typically by SWIFT or CHAPS electronic transfer) from the buyer's account 100 to the supplier's account 102 can be confirmed by the tapX engine 40 reading at 226 the current balance of both the buyer's and the supplier's bank accounts 100, 102. Then the bank movement is reconciled at 228 by matching payment instructions with bank cleared transactions and also by comparing the bank cleared balance on both the buyer and supplier bank accounts 100, 102 with an internal tapX ledger balance (not shown). A report is generated at 228 of the reconciliation results which includes any abnormalities found and this is forwarded at 230 to both the buyer 32 and supplier 36. At the buyer 32, the invoice status is updated at 232 as are both the GA and the procurement engine. At the supplier 36, the invoice status is updated at 234 as are both the GA and the sales engine.

Table 1 shows a summary of the six stages described above together with details of the communications on which the stages are based. More specifically, Table 1 sets out for each above described stage, the source of the communication to the tapX engine 40, the tapX interface used, the tapX task in the procurement/settlement cycle, the output generated by the tapX engine 40, the interface used for the output, and the destination for the output. Further, Tables 2 to 7 show respectively the procedures that are implemented at each of the above described processing stages of the settlement cycle in detail. Each table identifies the source of the input information, the information that is input, the task performed by the tapX engine 40, the output from the tapX engine 40, which types of users and business decisions are supported, and general comments on the stage. These tables provide the specifics to assist the notional skilled addressee to construct the current embodiment ofthe present invention.

The core payment status values that the tapX engine 40 manages take into account the quality of credit backing the buyer 32 requires to effect the purchase. The accuracy of this information on the quality of credit backing then allows suppliers 36 and their banks 38 to make appropriate and reliable decisions on trade financing. All information on credit quality and changes to payment status up to the point of payment execution are provided by the buyer 32, as has been mentioned previously.

The tapX engine 40 assigns and reports assured payments with two levels of credit quality:

A. Committed fund backing that cannot be withdrawn: via reserving funds from committed bank line or cash deposits; and

B. Covenant fund backing that could be withdrawn: via Corporate covenant or bank's general credit line (e.g. overdraft).

If the buyer 32 requires to back their purchase (or part ofthe purchase) with the higher level (Level A) of credit quality, e.g. the purchase of a bespoke machine tool from a supplier with whom the buyer 32 has no trading relationship or credit standing, then the purchase status that the tapX engine 40 manages during the procurement life- cycle, through to settlement will be:

1. ASSURED SUBJECT TO RECEIPT & INVOICE (backed by committed funds) - on order confirmation. - This commitment allows for potential for pre-invoice discounting. - If the buyer 32 requires only a part of the value to assured at this level, (e.g. full balance to be agreed only on inspection at delivery), then the quality of credit backing can be set at the level of part deliveries within the purchase order, with the balance set initially to credit quality B.

2. ASSURED SUBJECT TO INVOICE (backed by committed funds) - on acceptance of order delivery.

- The balance value can now be finalised and the credit backing level updated as required by the purchase. - This stage will not be required by some transactions where there is no formal receiving process (e.g. services).

3. ASSURED (backed by committed funds) - on matching of invoice to either an accepted delivery (if purchase requires three-way matching) or to purchase order (if purchase requires only a two-way matching).

4. REMITTED - on execution ofthe payment instructions by the tapX engine 40.

5. RECONCILED - on reconciliation of payment instructions, as executed by the tapX engine 40, with buyer/supplier banks 34, 38.

If the buyer 32 requires to back their purchase with the lower level of credit quality (Level B), e.g. a regular purchase from a regular supplier 36 with whom the buyer 32 already has a trading relationship or credit standing, then the payment status that the tapX engine 40 will manage during the procurement life-cycle, through to settlement will be:

1. PURCHASE ORDER CONFIRMED - on order confirmation.

2. ASSURED SUBJECT TO INVOICE (backed by corporate covenant) - on acceptance of order delivery. 3. ASSURED (backed by corporate covenant) - on matching of invoice to either an accepted delivery (if purchase requires three-way matching) or to purchase order (if purchase requires only a two-way matching). 4. REMITTED - on execution ofthe payment instructions by the tapX engine 40.

5. RECONCILED - on reconciliation of payment instruction with buyer/supplier banks 34, 38.

These categorisations of assured payments enable the tapX engine 40 to provide information on forward cash positions from transactions settled through the tapX system 30 (inward and outward cashflows). This is beneficial as it enables the following:

• Buyers 32 and suppliers 36 in the supply chain to manage funding requirements to cover payment liabilities (e.g. arrange committed credit lines or make cash deposits);

• Banks 34, 38 to manage trade finance decisions and credit risk management (assess their customers' collateral in terms of quality of forward inward cashflows);

• Banks 34, 38 to obtain information concerning receivables finance granted and to control and account for the cashflow associated with such financing; and

• Banks 34, 38 and the bank acting as Securitisation Manager to obtain information to facilitate the securitisation of receivables finance and to asset account for the securitisation programme and control associated cashflows.

These facilities are highly commercially advantageous because they enable buyers/ suppliers 32, 36 to optimise short term finance costs/returns to meet overall business objectives. They also enable banks 34, 38, to achieve a target return within an enhanced risk management framework and also enable strict control of receivables settlement such that cash is remitted directly to the financing party beneficially entitled to it. •

The buyer 32 is required to exercise available assurance options/facilities (credit qualities) in order to support the forward cash position facility in the tapX engine 40. The assurance can be 'Bank Assured' (backed by buyer cash deposits or committed credit lines) or 'Purchaser Assured'. These grades of credit quality further qualify the payment status value of assured (e.g. 'Bank Assured' is of higher quality than 'Purchaser Assured'). On setting up of standing data, (or for each transaction update) the buyer 32 specifies the default credit quality that underwrites their "assured" payments for any given supplier 36 (e.g. a regular supplier, benefiting from high volume of regular purchases/payments is set with a credit coverage quality type B, 'Purchaser Assured'. On the other hand, a new supplier of high value, mission critical materials, may demand that they have credit coverage quality of type A, 'Bank Assured'). These credit coverage quality types can readily be updated as trading relationships evolve between the buyer 32 and its suppliers 36.

In addition to seeing the funding required to cover the execution of approved payments, the buyer's treasurer will also see purchase orders for which the purchasing department requires a 'Bank Assured' status but for which there were no available funds or committed line at the time of initial capture in the tapX engine 40. The treasurer can then make arrangements for necessary funds and/or committed credit lines to be available on the tapX managed bank account 100 in order to cover this gap. On receipt of this new funding level, the tapX engine 40 identifies all purchase orders that require 'Bank Assured' backing but which currently do not have it, allocate cash or credit line values to them and update them from 'Purchaser Assured' to 'Bank Assured' on both the buyer's and suppliers' bank accounts 100, 102. The remaining 'Bank Assured' balance value for that account is simultaneously adjusted.

Supplier's treasury departments and their respective banks 38 are able to view forward cash inward flows by value day at various levels of drill down:

1. Summary of forward cash from the tapX engine executed trades by value date, which is broken down into different credit quality types: a. Current cash balance, +; b. Amount and % bank assured + purchase order confirmed ; c. Amount and % bank assured + goods delivered (on acceptance of delivery); d. Amount and % bank assured + invoice approved (on acceptance of invoice); e. Amount and % purchaser assured + purchase order confirmed; f. Amount and % purchaser assured + goods delivered (on acceptance of delivery); g. Amount and % purchaser assured + invoice approved (on acceptance of invoice); and h. Amount and % paid (on tapX engine execution).

2. Detailed view in which it is possible to drill down into each category to view . underlying transactions.

The supplier 36 and its bank 38 need to be able to view the profile of their forward cash outward flows by credit quality type relating to their own purchases (where they act as a buyer), in order to be able to arrange appropriate financing coverage:

1. Summary of forward cash from the tapX engine executed trades by value date, which is broken down into different credit quality types: a. Current cash balance, +; b. Amount and % bank assured + purchase order confirmed; c. Amount and % bank assured + goods delivered (on acceptance of delivery); d. Amount and % bank assured + invoice approved (on acceptance of invoice); e. Amount and % purchaser assured + purchase order confirmed; f. Amount and % purchaser assured + goods delivered (on acceptance of delivery); g. Amount and % purchaser assured + invoice approved (on acceptance of invoice); and h. Amount and % paid (on tapX engine execution);

2. Detailed view in which it is possible to drill down into each category to view underlying transactions.

3. Consolidated view of both inward and outward cashflows of their "supplier" and "buyer" positions, by value date, in terms of surplus or deficit. The consolidated view can be broken down into an aggregate view of 'Purchaser Assured' versus 'Bank Assured' and for deficits, a view of available "headroom" within general and committed credit facilities, namely facilities not yet drawn down. Suppliers 36 and their banks 38 can then advantageously arrange the following:

1. Fund coverage just ahead of payment execution for 'Purchaser Assured' payments (one or two days ahead of due value date, whatever the appropriate lead time is). These can be provided via cash or overdraft facilities.

2. Fund coverage for bank assured liabilities, such as a one-off purchase from a supplier 36 who has no credit profile of the buyer 32. This can be done via a committed credit line up to the liability's value date or via a cash deposit (or mixture of both). Alternatively, it is possible to use drawn credit lines after the liability's value date.

The tapX system 30 provides comprehensive support for the banks' credit decisions and offers highly flexible functionality in terms of fixed or floating interest rates, multi-currency and the percentage of individual purchase orders/invoices to be financed, giving the banks 34, 38 complete control over their financings being operated through the tapX system 30.

The suppliers 36 can use the tapX system 30 to ask their banks 38 for finance at various stages during the procurement and settlement cycles. More specifically, two types of finance available are:

• Pre-invoice finance (also known as purchase order finance), i.e. finance made available at any time after the purchase order is issued but prior to the invoice being raised; and

• Post-invoice finance, i.e. finance made available after the invoice is issued.

In general, post-invoice finance involves less risk, since (provided the invoice is not fraudulent) the goods will have been produced and shipped and there is therefore an increased likelihood that suppliers will fulfil the sales contract.

Finance can be made available on two bases:

• Receivable specific finance, i.e. separate advances as a percentage of individual invoices or purchase orders. This structured finance gives the banks 34, 38 greater control; or • Debtor book finance, effectively an overdraft backed by the collateral of a supplier's debtor book, including purchase orders and invoices.

These two options are described in greater detail below. Whichever ofthe two types of finance the supplier 36 selects, they specify to the bank 38 the amount required.

On receiving a request for finance via the tapX system 30, the bank 38 uses the tapX engine 40 to view the forward cashflow into the supplier's account 102, taking note of levels of 'assured payment' and makes a credit decision.

On receiving the bank's offer of finance (a decline is also possible), the supplier 36 either accepts or rejects the offer. Where an offer of finance is accepted, the tapX engine 40 is advised and funds are made available to the supplier's account 102 and the loan together with the associated forward receivable are transferred to the Supplier's Receivable Specific Finance Account.

This structured finance enables the bank 34, 38 to monitor the settlement of each receivable. The supplier 36 decides which invoices to finance subject to agreement of terms with the bank 38. They may select the larger invoices and credit periods, thereby maximizing finance for minimum administrative cost. Normally the bank 38 would authorize a percentage of each receivable to be financed, e.g. 60-90% with 70% being typical. This would depend on the quality of the buyer 32 and supplier 36 as well as the 'assured payment' status marked against each invoice.

Finance is available to the supplier 36 until maturity of the trade debt. On debiting these funds from the buyer's account 100, the tapX engine 40 ensures that all principal and interest are paid to the lending bank 38 prior to crediting the net balance to the supplier 36. The tapX engine 40 channels the receipt of funds directly to repay the loan and interest thereon rather than via the supplier's normal tapX bank account 102.

There are two forms in which this finance may be granted:

• Non-recourse invoice discounting: In the case of a bank 34, 38 providing this non-recourse finance, the tapX engine 40 discounts the invoice, i.e. pays up- front to the supplier 36 100% ofthe invoice's face value minus the full interest charge. The bank's sole source of repayment is the settlement of the trade debt by the buyer 32. The interest receivable by the bank 38 is a fixed amount irrespective ofthe actual date on which the invoice is settled. • A loan against a specific receivable: In this case the bank 34, 38 advances a percentage of the value of the receivable at an agreed interest rate. Interest accrues on a daily basis until settlement ofthe receivable.

The way in which the present tapX system 30 supports receivable specific finance outlined above is described in greater detail later.

The present tapX system 30 also supports debtor book finance. This type of finance is less structured than receivable specific finance and operates as an overdraft backed by the collateral of the supplier's trade debtors. Depending on the lending bank's risk appetite, finance can be made against 100% or less of the outstanding invoices and can also take into account purchase orders issued where:

• Goods are still under production; and

• Invoices have not yet been raised.

Under this arrangement interest is debited by the lending bank 34, 38 periodically in arrears. Each time a trade debt is settled by the buyer 32, the tapX engine 40 simply credits the funds to the supplier's account 102.

The buyer's bank 34 may at any time amend (i.e. increase or decrease) the committed credit limit available to a buyer 32. However, the bank 34 must continue to respect any prior commitments that are still outstanding. Similarly, the final maturity date of a committed credit limit can be modified, provided the bank 34 does not reduce the validity date to be shorter term than the expiry date of live commitments. These types of amendments must be communicated to the tapX engine 40 as they will almost certainly have some effect in its operation.

The supplier's bank 38 will also need to advise the tapX engine 40 of limits and terms and conditions of any finance being made available to suppliers 36 although the tapX engine 40 simply holds this information and does not have any involvement in administering these limits.

The tapX system 30 creates a suitable environment for future innovation: the buyer's bank 34 (and potentially other banks 38) are able to use the tapX engine 40 to submit bids for finance to suppliers 36 on individual invoices. The bank 34 takes comfort from the fact that it already has payment assurance from the buyer 32. The supplier 36 therefore benefits from the offers not only from its own bank 38 but also banks with which it may not have a previous business relationship. This would also be an opportunity for a buyer' s bank 34 to expand its customer base.

A bank 34, 38 has the option of selling loans financing specific receivables into securitisation pools operated by a lead manager subject to the loans falling within the established parameters for the securitisation program (established by the lead manager) and agreement of the interest rate at which they are to be sold. This securitisation advantageously removes the loan from the balance sheet ofthe bank 34, 38. The way in which the tapX system 30 handles securitisation is described in detail later.

Further general points regarding running ofthe tapX system 30 are set out below.

All RBP transactions are recorded on a tapX audit log (not shown). This is the basic requirement which enables reports to be generated on the performance of the system for example. The tapX audit log is stored on the database 66 ofthe GWS 60 and ofthe processing engines 64.

Controls exist within the tapX engine 40 to ensure that the data that is input is complete, and accurate. If incomplete, the tapX engine 40 has the ability to flag this to the inputting system a request that the complete data be sent. Similarly the tapX engine 40 ensures that the processing and output data is also complete and accurate.

Exception and management reporting is generated by the tapX engine 40 to provide information for tapX operations on various performance criteria, for example: summary information showing number and value of transactions processed by the RBP 32, and for the supplier 36 and bank 38, detailed transaction reporting showing every payment assured, processed, rejected. More specifically, information on the following criteria are provided: Failed payment approvals with reasons;

Authorised payments not made (within specified timescales);

Rejected approved pay instructions with reasons;

Summary of payments made to supplier (within specified timescales);

Summary of approved payments to be made to Supplier categorised by RBP; Daily opening committed balances, amounts paid during the day;

Amounts committed during the day and closing committed balances; and

Confirmation of changes in RBP and supplier standing data changes.

Information which is delivered from the tapX system 30 as a whole to each of its partners (buyers, suppliers, banks) is now described. For the tapX system management, the tapX engine 40 provides balance analysis, subscriber billing information and key performance indicators. For the RBP 32, the tapX engine 40 provides account balance information by group/department/supplier and statement information for a group or department or a consolidated view. For the suppliers 36, the tapX engine 40 provides account balance information by group/department/ supplier, and statement information for a group or department or a consolidated view. For the banks 34, 38, the tapX engine 40 provides account information such as forward cash positions, current balances, and credit limits on bank accounts, namely risk assessment.

The tapX engine 40 is configured to generate sufficient and accurate operational information regarding transactions undertaken by the tapX system 30 on behalf ofthe partner to enable tapX administrators to compile subscriber invoices as per the terms ofthe contract with the partner, for example the number of transactions processed, the value of each transaction processed, the timing of transactions, the number of failures etc. The tapX engine 40 can interface to the off the shelf general accounting system 48 of the buyer 32 to handle the administration of subscriber invoicing.

As mentioned previously, the present tapX system 30 supports receivable specific finance and this is now described in detail below.

Prior to the present invention, if a supplier 36 wished to obtain finance against a specific trade receivable the lender (bank) would advance funds to the supplier. 36 secured against the receivable. However, on settlement of the invoice the buyer 32 would pay the funds directly to the supplier 36.

The lender would therefore, be exposed in this situation to the risk that the supplier 36 would fail to apply the proceeds of the invoice in repayment of the loan. This may arise from a number of reasons such as the insolvency of the supplier 36 or the imposition of exchange controls if the supplier 36 and lender are in different jurisdictions etc.

Utilising transactional control features within the tapX engine 40, the payment made by the buyer 32 to the supplier 36 in settlement of a trade receivable against which a loan has been made will be automatically re-routed (without any action by the buyer 32) such that the funds required to repay the loan (principal and interest) are paid directly to the appropriate account with the lender, to which the supplier does not have direct access. This removes the risk that the supplier applies the funds for any other purpose or is unable to remit them to the lender for any reason. No additional exposure is taken to the supplier in respect of either credit or country risk.

More specifically, referring to Figure 13 the way in which the present embodiment of the invention solves this problem shown. When a trade payable/receivable is recorded at 240 on the tapX system 30, the tapX engine 40 automatically checks the payment path for that transaction based on standing data held and the verification ofthe actual existence of the underlying bank accounts. When the item is due for settlement the tapX engine 40 automatically instructs the systems ofthe buyer's bank 34 to effect the transfer and confirms receipt in the supplier's bank account 102 through interfaces 54 with the supplier's bank 38.

If a lender makes finance available against a specific trade receivable details of the loan transaction are recorded in the tapX engine 40. This triggers the following events:

(a) a new bank account 242 is created to record the loan ("receivable specific finance account" ("RSFA"));

(b) the amount advanced is transferred at 244 from the RSFA 242 to the supplier's normal bank account 102; and

(c) the payment path for settlement of the payable concerned is re-routed at 246 to target the appropriate RSFA 242.

On settlement at 248 of the invoice, the tapX engine automatically instructs the systems 48 of the buyer's bank 32 to effect a transfer to the RSFA 242 of the amount outstanding (principal plus interest) on that account and a transfer 250 to the supplier's normal bank account 102 of any excess. Interfaces with the lending bank and the supplier's normal bank 38 verify receipt of funds.

Note that the financing bank can alternatively decide to allow the supplier to overdraw his Account 102 into which the settlements are otherwise made. The practice of receivable specific financing versus pooled invoice financing will depend upon the bank's practice (which may be adjusted by the bank in response to tapX mechanisms). At all times the bank will have the information to enable it to decide upon the appropriate risk control.

The advantage of the above is that it increases a bank's financing opportunity by providing early visibility of the forward cash flows and also that it enables transfer of risk, which can reduce the economic or regulatory capital required for financing.

The risk transfer operates in two ways. Firstly, the credit is enhanced by attachment to the buyer's payment under which the loan and the interest is repaid before the supplier receives the balance. This payment is termed purchaser-assured. Secondly, the RBP's bank can attach a committed line to the RBP's account 100 covering the payment and making the forward payment bank-assured. Under these conditions the exposure of the financing bank is transferred to the RBP's bank. Subject to a central bank's approval of the quality of the collateral, the regulatory capital requirement ofthe financing bank can be reduced. Bank risk generally carries a 20% capital adequacy weighting compared with the harsher 100% weighting that is applied to corporate risk, even for those corporations with the best credit rating.

Where the trade is international, the country risk is advantageously transferred. This is very relevant in industries such as electronic components and garments, which are typically manufactured in developing countries.

As mentioned previously, the tapX system 30 can handle securitisation and this is now described in detail .

Banks 34, 38 have the opportunity to sell the loans made against specific invoice receivables into a securitisation program subject in compliance with parameters established by a lead manager. This is advantageous because it serves to remove such loans from the balance sheet of the financing bank 34, 38. However at present, it is difficult for a lender to securitise loans against trade receivables in a cost-effective manner. Inefficiencies arise in the process because an effective securitisation program has several requirements:

(a) a continuing flow of loans to securitise; (b) an ability to identify loans whose risk parameters fall within the scope ofthe securitisation programme;

(c) an efficient administration and record keeping concerning securitised loans; and

(d) an efficient administration of settlement of securitised loans.

The present embodiment of the invention addresses the restrictions on scope for securitisation outlined above in the following ways: (a) the ready availability of information concerning forward cashflows (a previously described characteristic of the tapX system 30) and the reduction in risk to lenders (the above described receivables financing process) make lending against trade receivables easier and less costly hence increasing the volume of loans made;

(b) The forward cashflow information and securing of the receivables financing process also facilitate the identification of suitable loans for securitisation;

(c) both the securitisation entity and the lender are be able to view details of securitised loans which are identified by flags (not shown) on the tapX system 30 denoting the securitisation pool to which they relate;

(d) the transactional controls within the tapX system 30 ensure that at settlement the appropriate funds are automatically paid to each party concerned (the securitisation entity, the lender and the supplier 36).

More specifically, referring to Figure 14, the way in which the present embodiment of the invention solves this problem shown. Securitisation is applicable to the loans made to finance specific trade receivables and thus the steps to securitise a specific loan take place subsequent to the creation of RSFAs 242 described previously in relation to secure receivables financing.

A securitisation entity ("SSPV") 252 for a particular programme opens a bank account on the tapX system 30 as do lenders on the tapX system 30 that wish to sell loans into securitisation programs ("pool funding accounts" ("PFAs")) 254.

A loan recorded in an RSFA 242 is sold at 256 by the lender to the SSPV 252 and details of the price (interest coupon) are entered into the tapX engine 40. The price and securitisation program number data are attached to the RSFA details. This data entry causes the tapX engine 40 to automatically execute at 258 a bank transfer of the principal amount of the loan from the SSPV's bank account 252 to the lender's PFA 254.

On settlement at 260 of the underlying trade, receivable funds are transferred to the RSFA 242 as described previously in relation to secure receivables financing (see Figure 13). Confirmation of receipt in the RSFA 242 automatically triggers a transfer at 262 of the principal amount plus accrued interest from the PFA 254 to the SSPV's bank account 252.

By attaching a securitisation program identifier to each RSFA 242 as applicable, it is possible for the programme manager to see full details of the securitised loans and underlying receivables by programme with no duplication of data.

This way of securitising the loan significantly reduces the risk to the securitisation entity 252 making the investment in securitised loans considerably more attractive since there is no direct credit or country risk exposure to the supplier 36.

Additionally, by providing all parties involved with different views of the same data the tapX engine 40 considerably reduces the cost of administration involved in a securitisation programme.

Referring now to Figure 15, an alternative preferred embodiment of the present invention is now described. The alternative embodiment is the same as the initially described embodiment in many ways and so to avoid unnecessary repetition, the following description is restricted to the differences between the different embodiments.

The major difference between the present embodiment and the previously described embodiment is that the tapX engine 40 manages directly accessible accounts provided in the banks of the supplier 36 and buyer 32. In the previous embodiment it was necessary to use external electronic fund transfer mechanisms which were generally available such as CHAPS and SWIFT to transfer funds between the supplier and buyer and special bank accounts set up by the buyer 32 and the supplier 36 for the tapX system 30 were required. However in the present embodiment, there is no need to use these indirect links as directly accessible accounts are provided as is described below.

Generally prior to the present invention, inter-bank money transfers have been effected by disconnected book entries: the buyer's bank, Bank A, makes entries into its records and sends a message (e.g. via SWIFT MT100) to the seller's bank, Bank B (or central clearing system), which initiates Bank B making book entries in its own records.

In the present embodiment, the tapX engine 40 which operates a multi-bank solution removes the need for external messaging, namely the initiation of a transfer from the buyer 32 to the supplier 36 automatically results in the accounts of both banks 34, 38 being updated.

More specifically, at the buyer's bank 34, a nostro bank account 300 in the name ofthe supplier's bank 38 is set up. Similarly, at the supplier's bank 38, another nostro bank account 302 in the name of the buyer's bank 34 is set up. Each of these nostro bank accounts 300, 302 is accessible by the tapX engine 40.

The tapX engine 40 reduces inter-bank settlement to two sets of book entries, one at each bank 34, 38 involved. Therefore, when funds have to be transferred from the buyer 32 to the supplier 36, this can be simply done by updating the buyer's account 100 at the buyer's bank 34 to show a debit and at the same time updating the supplier's bank's nostro bank account 300 at the buyer's bank 34 to show a corresponding credit. An equal debit is made to the buyer's bank's nostro bank account 302 at the supplier's bank 38 and a corresponding credit to the supplier's bank account 102. No external messaging is required. All the entries are initiated automatically from messages received from the buyer's order processing or invoice systems 48 via the tapX engine 40 in a straight through process.

The tapX engine 40 manages accounts for the buyer 32, the supplier 36, the buyer's bank 34 and the. supplier's bank 38 and generates the necessary account entries on both banks' nostro accounts 300, 302 and the accounts 100, 102 of the buyer 32 and supplier 36. The UBGs 62 of the tapX engine 40 comprise slightly modified bank drivers 306 which are each configured to access multiple bank accounts at a single bank. The tapX engine 40 provides integrated nostro reconciliation facilities for the buyer's bank 34 and the supplier's bank 38. Accordingly, after payment execution, the tapX engine 40 ensures that all entries have been correctly processed by a detailed reconciliation of transactions and nostro balances at both banks 34, 38.

At present a significant percentage of cross border commercial payment instructions require some form of manual intervention by the bank 34, 38 in order to be successfully executed. The tapX engine 40 of the present embodiment eliminates the need for these repairs by directly posting transactions to the suppliers' accounts 300 by a book entry process using dedicated nostro bank accounts 300. It leaves the balance on the nostro bank accounts 300, 302 for net settlement between the correspondent banks on capital account. Accordingly, the failure rate is significantly reduced.

The tapX engine 40 routes payments to the suppliers' accounts 300 without any clerical intervention on the part ofthe bank 32 which in turn reduces bank cost and the risk of a bank error. Furthermore, the present embodiment eliminates the bank's clerical effort. In fact, the payment into the suppliers' accounts 300 is the end of an automatic chain of events achieved from straight through processing attached to the purchaser's order processing or payables systems/ledgers.

The interbank nostro accounts 300, 302 are specific accounts for the execution of tapX initiated settlements. The management of the interbank liabilities generated are handled by the banks 34, 38 themselves as part of their overall relationship and can be cleared down daily or be subject to periodic or limit based settlement as required. This settlement is entirely at the discretion ofthe banks 34, 38 and the transactions initiated by them.

As has been explained previously, on the basis of categorising payables, the tapX system 30 can generate projection information, namely forecasts. Three examples of the types of forecasts which can be produced are set out in Figures 16, 17 and 18. Figure 16 is a graph of a cumulative liquidity ladder 310 which shows supplier's forecasted inflows over a period of 28+ days. The different categorisations of funds 312 are also shown to help the supplier 36 see the different levels of risk associated with each week's inflows. Furthermore, the cleared funds balance of today 314 is also shown on the graph to provide comparative information between inflows and balance.

Figure 17 is another graph of a cumulative liquidity ladder 310 which this time shows the supplier's forecasted outflows over a period of 28+ days. The different categorisations of funds 312 are again shown to help the supplier 36 see the different levels of risk associated with each week's outflows. The cleared funds balance of today 314 is also shown on the graph as is a committed credit line 316. The credit line helps the supplier see how likely he is to use up an existing credit line in the forthcoming weeks.

Figure 18 is a graph showing forward cash balances forecast. This graph is effectively created from an accumulation of information provided in the graphs of Figures 16 and 17. The graphical lines 318 enable the supplier to see what will be the likely cash balances for different scenarios of future inflows and outflows. Furthermore, a total credit line 320 is provided for comparison with the graphical lines 318, which enables the supplier to see potential risk of there being severe cashflow difficulties.

Having described particular preferred embodiments ofthe present invention, it is to be appreciated that the embodiments in question are exemplary only and that variations and modifications such as will occur to those possessed of the appropriate knowledge and skills may be made without departure from the spirit and scope ofthe invention as set forth in the appended claims. For example, it is to be appreciated that if the data was transmitted to the tapX engine 30 in the format of a flat file, then there would be no need for the UPG 58 as the format of the data and its completeness would be predetermined and would be guaranteed. Table 1 : Overview of Inputs and Outputs

CO c

COCO

n m co m m

C m ro

Table 2 Stage 1 -Setting Terms & Standing Data

CO c co^¬ co

m co m m

c m ro

Table 3 Stage 2: Placing Purchase Orders

Core Processing

co c

CO CO

J* m j co m m

c m ro

Table 4 Stage 3: Receiving Goods and Services

Core Processing

co c

CO CO

m co m m

c m ro

Table 5: Stage 4: Managing Purchase Invoices

Core Processing

CO c

CO CO

- m■ J §-»

CO

I m m

c m ro

Table 6. Stage 5: Paying Purchase Invoices

Core Processing

co c

CO CO

C I m o co m

m

c m ro

Table 7. Stage 6: Reconciling Operations

Core Processing

CO c

CO CO

m

c m ro

Claims

CLAIMS:

1. A back office settlement system for settling the finances of a transaction, the system comprising: input means configured to be responsive to input signals created in response to transaction events that occur throughout a purchasing transaction from order through to invoice, and an update engine operatively connectable to a vendor's bank and a purchaser's bank for updating the current balance of, and future cash positions of both the vendor's and purchaser's bank accounts with payment schedule data corresponding to the transaction events.

2. A back office settlement system according to Claim 1, wherein the payment schedule data comprises information regarding the payment status ofthe transaction.

3. A back office settlement system according to Claim 1 or 2, wherein the payment schedule data comprises instructions for executing a payment between a vendor's bank account and a purchaser's bank account.

4. A back office settlement system according to any preceding claim, wherein the update engine is arranged to generate vendor and/or purchaser general accounting update data and to transmit the accounting update data to the vendor and/or purchaser.

5. A back office settlement system according to Claim 4, wherein the update engine is arranged to transmit the vendor and/or purchaser general accounting update data to an accounting system ofthe vendor and/or purchaser.

6. A back office settlement system according to any preceding claim, wherein the update engine is arranged to generate a report of fund transfers and payment schedules relating to a purchaser or supplier, and to make this report available for remote viewing by the purchaser or supplier.

7. A back office settlement system according to any preceding claim, wherein the update engine is arranged to implement the updating procedure to both the vendor's and purchaser's bank accounts from a single transactional event.

8. A back office settlement system according to Claim 7, wherein the update engine is arranged to implement the updating procedure to both the vendor's and purchaser's bank accounts simultaneously.

9. A back office settlement system according to any preceding claim, wherein the update engine is arranged to carry out the updating procedure automatically, without user interaction following an initial set up.

10. A back office settlement system according to any preceding claim, wherein the input means is arranged to receive the input signals directly from a purchaser's transaction processing system.

11. A back office settlement system according to any preceding claim, wherein the update engine is connectable to multiple vendor and purchaser bank accounts.

12. A back office settlement system according to any preceding claim, wherein the update means is arranged to operate with multiple banks such that the vendor's and purchaser's bank accounts can be provided in separate banks.

13. A back office settlement system according to any preceding claim, wherein the system is arranged to be controlled by input signals received from the purchaser.

14. A back office settlement system according to any preceding claim, wherein the input means comprises a processing gateway for converting the format of the input signals into a predetermined internal format for processing.

15. A back office settlement system according to Claim 14, wherein the processing gateway is arranged to analyse the input signals for a predetermined input format and to transmit an error message back to the source of the input signals if the input signals do not comply with the predetermined format.

16. A back office settlement system according to Claim 15, wherein the processing gateway is arranged to accept a plurality of different predetermined input signal formats from different input sources.

17. A back office settlement system according to any of Claims 14 to 16, wherein the processing gateway is arranged to enhance input signals with additional information obtained from standing data relating to the purchaser or calculated from some received input signals.

18. A back office settlement system according to any of Claims 14 to 17, wherein the input means is operatively connectable to a plurality of purchasers and comprises a corresponding plurality of processing gateways.

19. A back office settlement system according to any of Claims 14 to 18, wherein the processing gateway is arranged to communicate the calculated schedule data to the purchaser for approval.

20. A back office settlement system according to any preceding claim, wherein the update engine comprises reading means having access to the purchaser's and vendor's bank accounts, the reading means being arranged to read account information from the bank accounts.

21. A back office settlement system according to Claim 20, wherein the reading means is arranged to read the available balance in the purchaser's bank account and a credit facility assigned to the account by the purchaser's bank.

22. A back office settlement system according to Claim 20 or 21, wherein the reading means comprises a bank gateway for updating the payment schedule data to the vendor's and purchaser's bank accounts.

23. A back office settlement system according to Claim 22, wherein the bank gateway is arranged to convert the payment schedule data into a predetermined format for the vendor's and purchaser's bank accounts.

24. A back office settlement system according to any of Claims 20 to 23, wherein the reading means comprises a plurality of bank gateways, each gateway being provided for a particular purchaser and being operatively connectable to each of a plurality of different banks.

25. A back office settlement system according to any of Claims 20 to 24, wherein the update engine is arranged to determine whether the financial settlement can be completed on the basis of read account information and the received input signals.

26. A back office settlement system according to any preceding claim, further comprising a communications server for enabling the purchaser and/or the vendor to make a status enquiry regarding the settling of finances of a transaction, the communications server being operatively connectable with a wide area network accessible by the purchaser and the vendor and being arranged to provide the status of the transaction settlement in response to the enquiry.

27. A back office settlement system according to Claim 26, wherein the communications server comprises a local database for storing a copy of transaction information processed by the update engine for use in providing the status of the transaction settlement in response to the enquiry.

28. A back office settlement system according to Claim 26 or 27 as dependent on any of Claims 14 to 19, wherein the communications server is connected to the processing gateway and is arranged to accept instructions from the purchaser or vendor via the wide area network, and to send the instructions to the processing gateway for use as input signals.

29. A method of settling the finances of a transaction, the method comprising: creating input signals representing transaction events that occur throughout a purchasing transaction from order through to invoice; inputting the input signals into a back office settlement system; connecting the back office settlement system to a vendor's bank and a purchaser's bank; and updating the current balance of, and future cash positions of both the vendor's and purchaser's bank accounts with payment schedule data corresponding to the transaction events.

30. A back office connect system for completing financial settlement of a transaction between a purchaser and a vendor, the system comprising: input means arranged to receive data relating to the transaction; reading means having access to the purchaser's bank account, the reading means being arranged to read the available balance in the account and a credit facility assigned to that transaction by the purchaser's bank; and categorisation means arranged to provide a secure categorisation of the type of payment that relates to the transaction according to the read information, such that a secure categorisation of future cashflow ofthe vendor can be determined.

31. A back office connect system according to Claim 30, wherein the categorisation means is arranged to compare the available balance and the amount of the credit facility of the purchaser's bank account with an amount of the transaction and to categorise the transaction payment in response to the result ofthe comparison.

32. A back office connect system according to Claim 30 or 31, wherein the categorisation means is arranged to instruct the reservation of a cash deposit and/or a credit line at the purchaser's bank account against a specific transaction and to change the categorisation ofthe transaction payment.

33. A back office connect system according to any of Claims 30 to 32, wherein the categorisation means is arranged to categorise the transaction payment as bank assured if the purchaser's bank account has cash and credit under a committed credit line sufficient to cover the amount ofthe transaction.

34. A back office connect system according to any of Claims 30 to 33, wherein the categorisation means is arranged to categorise the transaction payment as purchaser assured if the purchaser's bank account does not have enough cash and credit under a committed credit line sufficient to cover the amount ofthe transaction.

35. A back office connect system according to any of Claims 30 to 34, wherein categorisation means is arranged to report the categorisation of the type of payment assigned to the transaction to the purchaser.

36. A back office connect system according to any of Claims 30 to 35, further comprising a processing engine arranged to calculate scheduling information from the received transaction data and to use the scheduling data and the read information to determine the secure categorisation of future cashflow.

37. A back office connect system according to any of Claims 30 to 36, further comprising communication means for communicating the secure categorisation to the vendor's bank.

38. A back office connect system according to Claim 37, wherein the communication means is arranged to transmit the calculated scheduling data to the purchaser for approval.

39. A back office connect system according to any of Claims 30 to 38, further comprising decision means responsive to the categorisation means for determining whether the financial settlement can be completed.

40. A method of completing financial settlement of a transaction between a purchaser and a vendor, the method comprising: receiving data relating to the transaction; accessing the purchaser's bank account and reading the available balance in the account and credit facilities assigned to that transaction by the purchaser's bank; and providing a secure categorisation of the type of payment that relates to the transaction according to the read information, such that a secure categorisation of future cashflow ofthe vendor can be determined.

41. A method of effecting an electronic transaction between a vendor and a purchaser, the method comprising: receiving event data relating to the transaction including purchase order details ofthe transaction; and carrying out electronic scheduling and execution of payments to and from bank accounts of the purchaser and the vendor in accordance with the value of the transaction and in correspondence with the acceptable supply of goods or services that are the subject ofthe transaction.

42. A method according to Claim 41, wherein the receiving step comprises receiving transactional event data during the course of the transaction relating to acceptable receipt of goods and receipt of an invoice for the transaction.

43. A method according to Claim 41 or 42, wherein the receiving step comprises receiving instructions solely from the purchaser.

44. A method according to any of Claims 41 to 43, wherein the receiving step comprises receiving instructions solely from the purchaser.

45. A method according to any of Claims 41 to 44, further comprising changing the status of payment for the transaction in accordance with the progression of the transaction. >

46. A method according to Claim 45, wherein the changing step comprises considering value of cash and credit available to the purchaser at the purchaser's bank account.

47. A back office assured payment system which is configured to be responsive to an input signal, created in response to a transaction event, to update (credit and debit) automatically both a vendor's and a purchaser's bank accounts with data corresponding to that transaction event.

48. A method of repaying a loan to a borrower that is tied against future receivable funds, the method comprising: setting up a receivable specific finance account; re-routing a receivable funds payment path from an account ofthe borrower to the receivable specific finance account; and automatically repaying the loan on receipt of the receivable funds via the re- routed payment path to the receivable specific finance account.

49. A method according to Claim 48, further comprising calculating the interest due on the loan and wherein the automatic repaying step also comprises paying the interest on the loan.

50. A method according to Claim 48 or 49, wherein the setting up step comprises setting up a lender finance account and the repaying step comprises transferring at least an amount of the loan from the receivable specific finance account to the lender finance account.

51. A method according to any of Claims 48 to 50, further comprising transferring the loan amount from the lender finance account to the borrower's account prior to the re-routing step.

52. A method according to any of Claims 48 to 51, further comprising transferring any surplus funds from the receivable specific finance account to the borrower's account once at least the loan amount has been re-paid.

53. A method according to any of Claims 48 to 52, wherein the setting up, re- routing and repayment steps are all implemented from a back office settlement system which is connectable to a bank account providing the loan and the borrower's bank account.

54. A method according to Claim 53, wherein the receivable specific finance account is set up within the back office settlement system.

55. A method according to Claim 53 or 54, wherein the borrower's bank account and the bank account providing the loan are set up within the back office settlement system.

56. An apparatus for repaying a loan to a borrower that is tied against future receivable funds, the apparatus comprising: a receivable specific finance account; means for re-routing a receivable funds payment path from an account of the borrower to the receivable specific finance account; and means for automatically repaying the loan on receipt of the receivable funds via the re-routed payment path to the receivable specific finance account.

57. A method of providing and repaying a securitised loan to a borrower that is tied against future receivable funds, the method comprising: setting up a receivable specific finance account and a securitisation account of a lender; providing a securitisation loan from the securitisation account of the lender to the receivable specific finance account for payment to the borrower; re-routing a receivable funds payment path from an account of the borrower to the securitisation account via the receivable specific finance account; and automatically repaying the loan on receipt of the receivable funds via the re- routed payment path to the securitisation account via the receivable specific finance account.

58. A method according to Claim 57, further comprising: attaching details of the securitisation loan at the receivable specific account such that the repayment step causes transfer of the securitisation loan to the securitisation account ofthe lender.

59. A method according to Claim 58, wherein the loan repayment details stored in the receivable specific finance account are accessible for viewing by the borrower or the lender.

60. A method according to any of Claims 57 to 59, further comprising initially providing a loan from the receivable specific finance account to the account of the borrower, and making the loan available for sale in a securitisation funding pool for purchase by the lender.

61. A method according to Claim 60, wherein step of making the loan available in the securitisation pool comprises recording the purchase of the loan in a sub account for audit purposes.

62. A method according to any of Claims 57 to 61, further comprising calculating the interest due on the loan and wherein the automatic repaying step also comprises paying the interest on the loan.

63. A method according to any of Claims 57 to 62, further comprising transferring any surplus funds from the receivable specific finance account to the borrower's account once at least the loan amount has been re-paid.

64. A method according to any of Claims 57 to 63, wherein the setting up, rerouting and repayment steps are all implemented from a back office settlement system which is connectable to the securitisation account of the lender and the borrower's bank account.

65. A method according to Claim 64, wherein the receivable specific finance account and the securitisation account of a lender are set up within the back office settlement system.

66. An apparatus for providing and repaying a securitised loan to a borrower that is tied against future receivable funds, the apparatus comprising: a receivable specific finance account; a securitisation account of a lender; transfer means for providing a securitisation loan from the securitisation account of the lender to the receivable specific finance account for payment to the borrower; re-routing means for re-routing a receivable funds payment path from an account of the borrower to the securitisation account via the receivable specific finance account; and repayment means for automatically repaying the loan on receipt of the receivable funds via the re-routed payment path to the securitisation account via the receivable specific finance account.

67. A method of transferring funds between a purchaser and a vendor as part of a purchasing transaction therebetween, the method comprising: creating a first nostro account for the vendor's bank at the purchaser's bank and a second nostro account for the purchaser's bank at the vendor's bank; receiving input signals from a purchaser, the signals relating to at least one transaction event that occurs during the purchasing transaction and, in response thereto, instructing a fund transfer at both the purchaser's bank and the vendor's bank; and transferring funds internally within the purchaser's and vendor's banks from a purchaser's bank account to the vendor's bank's nostro account at the purchaser's bank and from the purchaser's bank's nostro account to a vendor's bank account at the vendor's bank, in response to the instructing step.

68. A method according to Claim 67, wherein the receiving step comprises receiving input signals from the purchaser's order/invoice system.

69. A method according to Claim 68, wherein the receiving step comprises receiving input signals relating to sending of an order, or notification of received goods or receipt of an invoice.

70. A method according to any of Claims 67 to 69, wherein the receiving step comprises the input signals being received by a back office connect system and being . transmitted onto the purchaser's bank and the vendor's bank.

71. A method according to Claim 70, further comprising converting the format of the input signals into a format recognised by the vendor's bank or purchaser's bank.

72. A method according to Claim 70 or 71, further comprising recording the input signals at the back office connect system to provide a view of the progression of the transaction and its settlement.

73. A method according to Claim 72, further comprising receiving a request for information relating to the settlement of the transaction and forwarding the same to the requesting party.

74. A method according to any of Claims 70 to 73, wherein each nostro bank account is accessible by the back office connect system and the instructing step is carried out by the back office connect system.

75. A method according to any of Claims 67 to 74, further comprising verifying the settlement of the transaction by carrying out a reconciliation of transactions and nostro balances at the purchaser's and vendor's banks.

76. A system for transferring funds between a purchaser and a vendor as part of a purchasing transaction therebetween, the system comprising: at a purchaser's bank, a first nostro account for a vendor's bank and a bank account for the purchaser; at the vendor's bank, a second nostro account for the purchaser's bank and a bank account for the vendor; a back office connect engine for receiving input signals from a purchaser, the signals relating to at least one transaction event that occurs during the purchasing transaction; and bank driver means responsive to the back office connect engine, for instructing an internal fund transfer at each of the purchaser's bank and the vendor's bank; the bank driver means being arranged for each transaction to generate instructions for two equivalent value fund transfers from the purchaser's bank account to the vendor's bank's nostro account at the purchaser's bank and from the purchaser's bank's nostro account to the vendor's bank account at the vendor's bank.

77. A system, method or apparatus substantially as described herein with reference to Figures 5 to 18 ofthe accompanying drawings.