GB2251098A

GB2251098A - Apparatus for processing data

Info

Publication number: GB2251098A
Application number: GB9027301A
Authority: GB
Inventors: Noel Mchugh
Original assignee: Allied Irish Banks PLC
Current assignee: Allied Irish Banks PLC
Priority date: 1990-12-17
Filing date: 1990-12-17
Publication date: 1992-06-24
Anticipated expiration: 2010-12-17
Also published as: GB2251098B; GB9027301D0

Abstract

Apparatus for processing data relating to the transfer of funds between accounts comprises a computer system including a payments router (103), the central processor of which is arranged to receive a payment instruction and to carry out a sequence of steps in which the source and destination of each payment are identified, and parts of each payment instruction are reformatted into a format acceptable to the computer system concerned to generate an account enquiry validating the beneficiary account particulars, an enquiry as to the sufficiency of funds in the source account, and the debit and credit instructions for the source and beneficiary accounts. Provision may be made for operator intervention. All transactions may be recorded in a transaction log file to provide a complete audit trail. <IMAGE>

Description

APPARATUS FOR PROCESSING DATA The invention relates to apparatus for processing data relating to the transfer of funds between accounts.

The invention is concerned with a computer system designed to carry out transactions comprising the transfer of funds between bank accounts. The banking group using the system may extend over several countries, and accounts may be of different types and in different currencies.

The banks and branches within the banking group using the system may use different computers for their accounting. Transfers of funds will have to be made to banks outside the group, who will generally also use different data formats for the transmission of accounting information. The system of the invention therefore includes means for storing the message format requirementS of each destination address, and also routing information. For example, it may be necessary for funds to be transferred to some overseas banks by mail or by telegraphic transfer, whereas others can accept direct electronic transfer instructions.

Transfers of funds may take place between accounts within the same branch of a bank, between different branches of the same bank, between different banks in the same country, or between banks in different countries.

It may be convenient for some transfers to be processed on-line, while others of lower urgency, or concerning future payments, are assembled into batch files and are processed after the close of each working day.

As in all banking matters, the system of the invention is designed to provide a high level of security. Data may be encrypted for transmission, access to the system may be limited by passwords of different security levels, transactions of an unusual nature or amount may be reported for manual verification, and limits may be placed on the sums transferred, or the accounts from which they are to be drawn or to which they are to be credited. Payment instructions may be validated in respect of the account-holders name, account number, the branch in which the account is held, and any limits which may have been imposed on the amounts to be transferred.

Customers may be required to input a personal identification number. Check digits may be used to detect and/or correct errors arising in data during transmission, or from errors in data entry. Certain of these methods are well known and will not necessarily be specifically mentioned below in describing the invention.

An essential feature of the system of the invention is that it should produce adequate transaction records, so that the customer has confirmation, first, that his instructions have been received, validated and accepted, and then that the transaction has been duly carried out in accordance with his wishes. The system must keep a log of every stage of each transaction for audit purposes.

It is an object of the present invention to provide apparatus for processing data, and in particular for transferring funds between bank accounts, which is designed to meet the above requirements.

The invention will now be further described with reference to the accompanying drawings, in which Figure 1 is a schematic block diagram of the system, and Figure 2 is a diagram of that part of the system which is concerned with the generation and routing of payment instructions.

Referring first to Figure 1, the major components of the system are shown schematically in block diagram form, with the flow of information between the items represented by the blocks being indicated by numbered arrows.

The system consists, in outline, of a hub, 101, which receives an input from a customer's computer, 102, validates and acknowledges the input, reformats it as necessary, and transmits it to a payments router 103, which will be located in the chief office of the bank.

The payment router analyses the input, determines the route for making the payment, generates the payment instructions, receives confirmation that the payment has been effected, transmits confirmation to the hub, and generates advice notes, reports, transaction logs, and any error messages or requests for manual intervention that may be necessary.

The system will now be described in more detail.

The hub, 101, will be installed at a central site adjacent to the bank's main computers. It comprises a number of computers connected in a network. Generally there will be at least four such computers, one or more, such as 104, being dedicated to communication with the customers' computers and so receiving the initial input data, another, 105, acting as an interface for communication with the payment router, another, the funds transfer computer 106, validating and storing the input messages for onward transmission, and a further one at least, 107, being reserved for holding the customer accounts and maintaining records of their balances and operating details.

Payment instructions to the bank are prepared and verified by the customer on his computer 102 on his own premises, and may be assembled into a batch file to be stored until released by an authorised official for transmission to the bank. Transmission may be over the normal telephone system, or a dedicated data line may be installed. As is customary in data transmission, error-correcting codes will normally be employed, and the data may be encrypted before transmission and decrypted on receipt.

The steps involved in carrying out a typical transfer of funds using the system of the invention will now be described, each step in the process being indicated by a correspondingly-numbered arrow-head in Figure 1.

Initially it will be assumed that the customer has entered particulars of all the funds transfers he wishes to initiate into a batch file in his computer 102 for transmission when authorised by an official of the company.

1. An authorised official at the customer site verifies the payment requests and authorises their release to the bank. To release a payment request the official must be in possession of a key disk, which permits release, and which provides the unique encryption key for encrypting that customer's messages. This process initiates the communications link between the customer's site and the communications computer 104 of the hub. After initial handshaking the following take place: 2. The customer requests any outstanding transaction serial numbers confirming receipt of previous transaction files.

3. If such exist, the hub communications computer 104-transmits them back to the customer.

4. The batch file which the customer has prepared is now transmitted to the hub 101, where it is received in the communications computer 104.

This computer adds a transaction serial number to each entry, and a status field which will be repeatedly updated as the transaction is processed through the system.

5. The file is now sent to the funds transfer computer 106, where it is validated for internal consistency, and checked to ensure that it conforms to any instructions held by the bank relating to the management of the account.

6. Error messages are generated in the computer 106 for any item which fails the validation, and the status field is suitably updated. The transaction numbers and status fields are returned to the communications computer 104.

7. If the customer is still on line the transaction numbers and any error messages are transmitted back to his computer 102. If not, they are assembled into a batch file for transmission to him on the next occasion on which he establishes contact.

8. The interface computer 105 continually polls the funds transfer computer 106 for further funds transfer instructions. As it receives them it re-formats them into a standard format for transmission, and assembles them into a file for transfer to the payments router 103.

9. The interface computer 105 establishes contact with the payments router 103. After the initial handshaking steps the interface computer requests any outstanding confirmations, these representing successful transfers of funds initiated by the previous contact.

10. The outstanding confirmations are downloaded into the interface computer, where they are stored.

11. The new instructions held in the interface computer 105 are transmitted to the payments router 103.

12. The payments router 103 checks the destination account nominated in the payment instruction to ensure, in the case of an internal account, that the account exists, and, in the case of an external account, that it is a valid destination. The router then identifies the system which carries the account to be debited, and then queries that account to establish the availability of funds to cover the payment.

13. Payment instructions are generated by the payments router. The payment format is dictated by the destination account and the associated transmission system. The payment may be sent internally to one of the bank's own computers, via the S.W.I.F.T. network to an external bank, or filed for inclusion in the end-of-day internal or inter-bank processes.

If funds are not available, no payment instructions are generated.

14. A response is sent to the hub from the payments router indicating whether or not the payment has been successfully carried out.

15. The payments router generates a confirmation for each of the urgent payments (i.e. those requiring to be acted on immediately) that has been carried out successfully.

16. The payments router generates branch advices advising each branch of any transfers relating to their customers that have been made on line.

17. Instructions are prepared by the payments router for any inter-bank payment which could not be made electronically.

18. The confirmations of successful payments, and messages relating to failed payments are assembled into a file and downloaded directly to the interface computer 105.

19. The information held in the interface computer 105 is now used to update the database held in the funds transfer computer 106 by updating the status fields.

20. The interface computer 105 generates a file of confirmations and passes it to the communications computer 104.

21. The customer is now able to call up the hub and confirm whether payments have been made.

22. The communications computer 104 passes to the customer's computer a list of confirmations confirming the payments that have been made, together with any error messages that have been generated.

The functioning of the payments router 103 will now be described in more detail with reference to Figure 2.

When a payment instruction is received from the hub 101 it is stored in a buffer register 201. This holds, in addition to various status flags and keys associated with the instruction, the identification of the source account and destination account, the amount and currency to be transferred and the effective date of the transfer. The central processing unit 202 of the payments router allocates a confirmation status to the instruction and re-transmits it to the hub as confirmation that the instruction has been received. At the same time an entry is made in a transaction log file 203. This file receives an entry for every message, transaction and action taken by the payments router, thereby providing a complete audit trail.

Next, the payment instruction is analysed to determine the type of payment, which will determine the action to be taken. It may require an urgent payment to be acted on immediately, or a normal payment to be processed overnight by the normal Electronic Money Transfer system at end-of-day.

If the payment instruction is for an immediate payment, the central processing unit 202 next interrogates the portion of the instruction which identifies the destination account for the payment, and calls up an inquiry template from an inquiry template store 205. This template is used to reformat part of the payment instruction into a format acceptable to the computer system of the beneficiary's account as an account enquiry, and it is then transmitted via a communications interface 206 to that system by way of an inquiry as to whether the account details are correct.

Assuming that the credit account exists, the central processing unit 202 next calls up a further template from a debit entry template store 208 which formats the debit portion of the instruction into a form which the system of the payer's account will accept as an instruction to debit the account. This instruction is then transmitted to that system.

If funds are insufficient the information is displayed on an operator's console 207, where a decision is made either to reject the transaction, in which case a message is passed back via the hub, or to allow it to proceed. Each message or transaction is, of course, recorded in the transaction log file 203 to ensure that the audit trail is complete.

The credit portipn of the instruction must now be processed, and first it is examined to determine where the destination account lies. It may be in the same branch of the bank as the source account, in a different branch of the same bank, in a different bank, which generally will have a different computer system and will require its instructions in a format recognisable by that system, or in an overseas bank which will also require also a currency conversion to be carried out, and which may call for special methods of payment, such as mail or telegraphic transfer of funds.

The central processing unit 202 now interrogates the payment instruction and calls up the appropriate credit entry format from a credit entry format store 209. This takes account of any currency conversions that may be required and the need for any special method of payment, and the credit instruction is formulated accordingly. According to the circumstances the credit instruction may be transmitted directly to the computer system of the destination account, (internal payment), stored in a batch file 210 for onward transmission at the close of the working day, formulated as a telegraphic transfer and sent to the destination bank, or routed to an operator for the preparation of a mail transfer.

At each of the steps described above an entry is made in the transaction log file 203, so that a complete record exists which provides an audit trail, and which also provides a means of tracking any error or malfunction which may occur in the system.

All normal messages (value date 2 days hence) are grouped together in a batch file 210 for input at end-of-day into the bank's overnight processing.

Claims

1. Apparatus for processing data relating to the transfer of funds between accounts and comprising a computer system including a payments router (103), the payments router including a central processor (202), an enquiry template store (205), a debit entry template store (208), and a credit entry format store (209), and in which the central processor is arranged to receive a payment instruction and to a) examine the destination field of the instruction to identify the destination account for the payment, b) call up the appropriate inquiry template from the inquiry template store and therewith to reformat part of the payment instruction into a format acceptable to the computer system of the beneficiary's account as an account enquiry, c) transmit the enquiry to that system to confirm that the destination is a valid one, d) examine the source field of the instruction to identify the payer's account, e) call up the appropriate inquiry template from the inquiry template store and therewith to reformat part of the payment instruction into a format acceptable to the computer system of the source account and transmit it as an enquiry as to whether there are sufficient funds in the account to meet the payment, f) on such confirmation to call up a further template from the debit entry template store and therewith format the debit portion of the instruction into a form which the system of the payer's account will accept as an instruction to debit the account, g) transmit the formatted instruction to that system, h) call up the credit entry format appropriate to the destination account from the credit entry format store, i) formulate the credit portion of the instruction in accordance with the credit entry format for transmittal or further processing.

2. Apparatus according to claim 1 in which the central processor is further arranged, on identifying a failure of confirmation in step c) or step e), thereupon to produce a message at an operator console, and to accept a further instruction entered at the console.

3. Apparatus according to claim 1 or claim 2 in which the central processor is further arranged to identify all normal messages (i.e. those having a value date two days ahead) and store them in a batch file for input at end-of-day into the bank's overnight processing.

4. Apparatus according to any preceding claim including means for generating and storing a transaction log file in which the central processor records each message or transaction to provide a complete audit trail.

5. Apparatus for processing data relating to the transfer of funds between accounts and comprising a computer system including a payments router organised and arranged to operate substantially as indicated schematically in and as herein described with reference to the accompanying drawings.