HK1079870A - System and method for multicurrency and multibank processing over a non-secure network - Google Patents

Description

System and method for multi-currency, multi-banking over an insecure network

no marking

no marking

no marking

Field of the invention

The present invention relates generally to conducting financial transactions over the internet and, more particularly, to using the internet for multi-bank and multi-currency online transactions and cash statements.

There are various conventional methods and systems whereby a customer of a financial institution can initiate and receive statements regarding multi-bank/multi-currency transactions.

In one previous approach, the customer had to communicate directly with a separate bank. In all cases, the customer needs to use separate communication software and separately establish a connection with the bank. This process is time consuming and cumbersome. Communication with a separate bank can be achieved in several ways. In one particular past approach, customers have manually called individuals at banks to provide instructions for transfers on the phone and/or to receive transaction data for balancing accounts.

In another previous approach, the customer uses the bank's proprietary software or a popular communications software package to dial through the bank's host system via a terminal emulation. The balance transaction data is downloaded from the bank using the bank's proprietary electronic banking software and offline transfer instructions are entered/approved and then the transaction is released in batches to the bank's system.

Each of these previous systems suffers from several disadvantages. In the customer side, extensive training and knowledge about the bank's proprietary systems is required. These systems are difficult to deploy and maintain and are generally not user friendly. Because these methods are typically batch-driven through the host process, timeliness of feedback to the customer is of great concern. Furthermore, transactions can only be processed from the customer due to trust in the software of the device at the customer. When a customer has a banking relationship with several banking institutions, each of these problems will be multiplied and mixed with each other. The customer must establish separate communications per each of their banks, maintain separate software packages, remember separate user ids/passwords, handle various security devices, pay separate software license fees for his banks, learn to use different transaction entry screens and interface with separate transaction databases.

Summary of the invention

The present invention solves most of the problems of previous systems and methods by providing bank customers with the ability to communicate with a single bank using the internet. With a single bank, the customer has the ability to process all of their bank bills at any bank for transaction reporting and transaction initiation. This eliminates the need for the user to establish separate communications with their different banks, maintain different software packages, and remember different user ids/passwords. The various security devices are processed, the respective software licensing fees required by their banks are paid, different transaction input screens are learned to be used, and the inefficiencies of operating the respective transaction databases are eliminated.

By using the internet, customers no longer need to be concerned with keeping their software up to date. Changes to the system and upgrades to the software can be automatically configured electronically to the customer by the world wide Web (Web). Because the present invention requires only small client software, customers can access the system anywhere the world wide web exists.

Using a standard Internet browser, financial institution customers can access the funds transfer and information reporting system of the present invention. Access to is restricted based on the user's security authorization profile and access rights. Once logged into the system, the user can provide instructions to transfer funds from them on the financial institution's account, or to transfer funds from an account at any other financial institution. In addition, the customer can view details of the account maintained at that financial institution or at any other financial institution in the same conversation.

The funds transfer instructions are entered on-line through the data screen. The online transaction can be in the form of a predetermined or free-form instruction. A predetermined instruction includes information predetermined with the bank. The predetermined instruction can be input by using a reference (line) number. The online transaction can also be entered in a free format. Furthermore, online transactions can involve several banks and several different currencies. Once multi-bank/multi-currency online transactions are entered, they can be approved and released by the user with the appropriate security authorization profile and access rights.

If the online transaction is purely internal to the bank (between two accounts at the same bank), the transaction is routed to the bank's money transfer system. If the online transaction involves transferring money to another bank, the instruction (or money) is routed to the other bank.

Customers can draw balance bills and transaction reports from their required deposit accounts, controlled payment accounts and Lockbox (Lockbox) accounts for that and other financial institutions. Other banks send their statements to the financial institution, which merges them in a unified statement format and submits them to the customer.

Brief description of the drawings

For the purpose of illustrating the invention, there is shown in the drawings a form which is presently considered to be preferred, it being understood, however, that the invention is not limited to the precise forms shown in the drawings, in which:

FIG. 1 illustrates a high level system flow diagram of the present invention;

FIG. 2 depicts a summary screen of the system of the present invention;

FIG. 3A illustrates a screen for adding a main line transaction;

FIG. 3B shows details regarding the ultimate beneficiary (ultimate beneficiary) for an added online transaction;

FIG. 3C depicts details associated with a benefited bank for an added online transaction;

FIG. 3D illustrates details about an intermediary bank for an added online transaction;

FIG. 3E illustrates details of adding payment for an online transaction;

FIG. 3F depicts additional details for adding an online transaction;

4A-4F illustrate details required to add an Internet account transfer transaction;

FIGS. 5A-5D depict information required to add a Draft (Draft) or check transaction;

6A-6C illustrate details required to add an Advice receive (Advice receive) transaction;

7A-7E illustrate the use of repeat lines in establishing a multi-currency/multi-bank debit (draw down) transaction;

FIG. 8 illustrates the main screen of a Cash statement viewer (Cash Reporting View) of the present invention;

FIGS. 9A-9D depict the current day's balanced account and transaction Detail (Transactional Detail) report;

10A-10G illustrate balancing accounting and transaction details for activities on a previous day, including account details for two different accounts;

11A-11C illustrate summary reports listing transaction activities since the last customer visit;

FIG. 12 shows a back table of balance bills for the previous day; and

FIG. 13 is a statement listing in descending order to requested Deposit Account (Demand Deposit Account) posting (post) checks.

Detailed description of the invention

The present invention consists of two important functions offered to the customers of a financial institution (bank). The first function is a multi-bank/multi-currency online transaction capability and the second function is a cash statement function capability. One unique aspect of the present invention is that it enables each of these individual functions to be accessed and used by customers through a single unified interface over the public internet.

FIG. 1 is a high level system flow diagram in accordance with the present invention. Element 10 represents a workstation located at a customer of a financial institution. Typically these workstations 10 are Personal Computers (PCs), but may also be more advanced graphics workstations or simpler web-enabled Personal Digital Assistants (PDAs). The only real requirement is to be able to connect to the internet. The workstation is connected to the bank through the internet and through the bank's firewall 12. The firewall 12 is a well-known security device that prevents unauthorized users from gaining access to the internal banking system.

The application server 14 is where most of the processing of the present invention is performed. These servers 14 house application software and databases for performing certain key aspects of the method of the present invention. The server 14 serves as a link between the customer workstation 10 and the bank's back-office systems 16, 18, 20 and other bank's systems 22, 24. For online transactions, the back office processing system 16 serves as the front end of the funds transfer system 20. The funds-transfer system 20 is a device that employs conventional techniques and processes the actual instructions for processing the transaction. The funds-transfer system 20 sends these instructions to the funds-transfer systems of other banks through a system such as SWIFT (worldwide institute of financial telecommunications). Although shown as two separate components in fig. 1, the post-occupational transaction system 16 and the funds transfer system 20 may be implemented as a single system.

The information reporting system 18 enables the present invention to have a cash reporting feature. In addition to containing all information about a customer's account with the bank, it can also interface with the reporting systems 24 of other banks to obtain account information for the customer from those banks, as will be described further below.

The online initiation feature of the present invention allows customers of the bank to enter into Funds Transfer Transactions (FTT-Funds Transfer Transactions) processed by the bank for intra-bank transfers or inter-bank transfers. FTTs entered by customers can be entered via a keyboard (scratch) (freeform) or according to a set of pre-established details (repeat lines). The FTT can request that lines be transferred in any amount. The system of the present invention further allows customers to review, approve and release the FETs, as well as provide reporting functions regarding FTTs.

The present invention supports both native money transfers (DMT) and Global Money Transfers (GMT). The following transaction types are supported for DMT transfers: dollar (USD) debit (Draw down) (feed-Fed and billing-Book); a USD feed; USD CHIPS (bill exchange inter-bank payment system); and USD billing (Book) support the following transaction types for GMT transfers: TLX (facsimile); IAT (inter account transfer); DFT (check); GIRO (designated as a domestic settlement system, such as the post office, this low-interest payment); ATR (Advice to Receive-Notification reception) and GMT borrowing.

To access the functional parts of the present invention, the customer simply accesses the bank server 14 through the internet and through the bank's firewall 12. This access can be accomplished using standard browsers and security techniques. As briefly mentioned above, access need not be to a workstation at a particular customer location, but may occur from any location through a PDA or other device.

Fig. 2 shows an initial summary screen presented by the system of the present invention once a customer has accessed the system via the internet. As can be seen in fig. 2, the user has the option to select the following function keys from the initial screen: approved 210; an increase (Add) 220; modify (Modify) 230; release (Release) 240; and Delete (Delete) 250. Details of each of these function keys are described below.

This summary screen 200 further includes an area 260 listing transactions. The listed transactions are in response to user selection of a view from the list box 270 generated by the view button 280. When the user selects the view button, the software provides a list box 270 that includes each of the transactions that are in progress, which can be seen and operated on in area 260.

The types of transactions that may be selected from the list box 270 include: input group non-approved transactions that only show transactions that have an input (ended) status for all dates; approved but unreleased transactions, which only show transactions with an Approved (Approved) status for all dates; the trade Released on the day, which only shows the trade with Released (Released) status and the date Released on the day (note: this is not the date of rest); release All data (Release All) transactions, which only show transactions with Release status for All dates; released but not confirmed transactions, which only show transactions with pending status for all dates; transactions that have expired on the previous 30 days, which shows all transactions that have an expiration date within the last 30 days; all views showing all transactions; a line graph showing all the repeated lines (described below) according to the claims; a Future origin (Future Value) graph of all transactions for any state is displayed, where any origin date is a date after the current day. Selection of these maps will cause transactions that fit the criteria of this map to be displayed in area 260. The view selected in the example depicted in fig. 2 lists the transactions released for the current day. As seen in area 260, only one transaction is released on the day.

If the user wishes to Add a new transaction, she selects the Add (Add) key 210 on the summary screen of FIG. 2. This action causes an incremental masking as shown in FIGS. 3A-3F, which in the incremental example shown in FIGS. 3A-3F, the customer adds a free-form transaction. In free-form input for a transaction, the customer must proceed with all details (e.g., amount, beneficiary … …) relating to the transaction. In contrast to free-form transactions, users have the option to add transactions based on a predetermined set of transaction data called repeat lines. Repeat lines are used when a customer performs a transaction with substantially all of the same transaction details with only a small amount of change (e.g., value passed). For example, if a customer pays the same lockseller for a long period of time, month after month, most transaction details (e.g., the seller's bank) do not change except for, for example, the transaction amount or the transaction's day of interest. In this case, the customer should set up and maintain a repeat line containing all the permanent transaction data associated with the payment to the merchant. Repeat lines to a customer can be initially established by electronically downloading from the customer the past history at the bank from the customer or from information provided by the customer. The customer can further add repeat lines as permanent repeat lines on an ongoing basis by saving a freeform transaction that is set up as described below.

The transaction is added to the system from the Add (Add) screen. The add screen consists of 300, 324 and 302 parts. The user can navigate between the display panels 300, 324, and 302 using conventional Graphical User Interface (GUI) techniques. The first stage is a Settlement (Settlement) information display panel 300, which consists of Settlement-type information for that transaction. The second segment is a total transfer display panel 324 that allows the customer to enter details of the day of interest, currency, quantity and instructions. The third section is a payment instruction display panel 302, which provides a series of sub-display panels (described below) that allow the customer to enter details of the transaction.

The user selects a free format from the row number combination list box 304 in the settlement information display panel 300 in order to input a free format transaction. The choice of freeform line indicates to the system that the user is to enter a non-duplicate transaction. Another approach is for the user to manually enter "free form" into the Line # combo list box 304 on the keyboard. Once the user selects the free format, the user enters information from the keyboard. All information must be completed in the settlement information display panel before the user enters the total number of transfers display panel 324 and the payment instruction display panel 302 to complete the transaction.

After the user selects the free-form input of the FTT, the user must indicate the number involved. To do so, the user can click on the Account # button 306 and select one Account from the accounts listed in the pop-up box (not shown). The accounts button 306 displays a list of accounts according to the user's rights. The account to which the user is authorized to access is contained in the bank's database and can be looked up as the user's right. The pop-up window displayed after pressing the account button 306 will display the following data fields: a bank name; branching; the currency of the account; an account number; and an account name. The accounts may be sorted by data column (ascending/descending order) within the list window. In addition, the user can also enter the account number directly into the account number combo box 310 via the keyboard. Entered into the combo box 310 is the content most sensitive to the first character, matching the keyboard entry to the row in the list.

As described above, the currency field 308 displays the currency of the selected account. The currency field 308 is a read-only field depending on the account selected and cannot be modified by the user. The bank name (ID) field 312 is a read-only field showing the bank name and location for the selected account. The bank name 312 is fixed for the account number selected by the user. The bank's line is a read-only field that displays the line number of the selected bank. In the example shown in FIG. 3A, the user enters a free-form transaction, so this field is shown blank. Field 316 shows the name of the account selected by the user, while field 318 shows the bank branch holding the account. Bank 312 and branch 318 are associated with account number 310.

The user can select the type of settlement, payment 320 or credentials 322, associated with the FTT. The particular payment method desired by the user is entered in field 324. The allowable payment method is based on the account number 310 and the settlement type (payment 320 or security 322) when the customer has selected in the settlement information display panel 300. If the user indicates that this transaction amount is paid, and if the payment is of DMT (national money transfer) type, the payment method authorized is Feed (FED), Bill (BOOK) or CHIPS (clearinghouse banking payment system). If the payment is non-DMT, the user in Asia must select TLX, IAT or DFT or GIRO if the transaction is to. If the user indicated a DMT security, the payment method must be FED or Book. If the voucher is not a DMT, the payment method for Asian transfers is ATR (Advice to Receive) or IAT (InterAccount transfer), or GIRO (designated as Low-interest Payment for national settlement systems).

Below the settlement information display panel 300 is a transfer amount display panel 324. The transfer amount display panel 324 allows the customer to enter the date of the origination, the currency of the transaction, and the amount. The transaction amount display panel 324 includes a date of expiration field 326 in which the user enters the date of expiration for the FTT. The format of the date display can be constructed by the user's preferences. If the user clicks on the date of interest button 328, a date appears allowing the user to easily select the date of interest for the transaction. Transfer currency field 330 shows the currency of the FTT and provides a list of available SWIFT currencies for selection by the user. The currency table shows the currency code and its description. The transaction amount field 332 is where the customer enters the transaction amount. The maximum number of transactions allowed is based on the number of transactions. The maximum number of transactions allowed is the maximum allowed by the currency of the transaction, SWIFT. The transaction amount is formatted when the user completes the entry and removes field 332.

The payment instruction display panel 302 for a free-form transaction contains payment routing information for the transaction. This routing information is identified in combination using a table selected by the user. Each table shows a different display panel to enable the customer to enter details of the payment instructions. The number and type of tables that the user can select and the data content displayed in each table are based on the post-transaction (driven by account number), the settlement type (e.g., payment or voucher), and the transaction type (DMTak GMT). The tab key on the user's keyboard using conventional GUI standards is used to move from one field to the next on each display panel. Pressing tab key again in the last field moves to the next block. The user can move between the previous or next display panel at any time using up/down or left/right arrow keys. Among data blocks having multiple lines of information (i.e., addresses and references), a user cannot skip a line and leave an empty line. For example, the user is not allowed to leave address row 2 blank and enter data in row 3.

In FIG. 3A, a summary table 334 is shown in payment instruction display panel 302. The display panel associated with summary table 334 also displays a summary of the details of the transaction. In the example depicted in FIG. 3A, each field displayed is blank, since the user has not entered details of the payment instruction in this example.

Fig. 3B shows the payment instruction display panel 302 when the user has selected the final beneficiary form 336. Indicating that the closed panel allows the user to enter details of the final beneficiary of the FTT, including an identifier 338 of the final beneficiary, a name 340 of the final beneficiary, and an address 342 of the final beneficiary.

Fig. 3C shows payment instruction display panel 302 when the user has given a selected final benefit bank table 344. The display panel associated with this table allows the user to enter details of the bank used by the ultimate beneficiary of the FTT, including the name 346 of the ultimate beneficiary bank and the address 348 of the ultimate beneficiary bank.

FIG. 3D shows the payment instruction display panel 302 when the user has selected the intermediary's table 350. The display panel associated with this table allows the user to enter details of the intermediary bank that are intended to be involved in this FTT, including the name 350 of the intermediary bank and the address 352 of the intermediary bank. While some customers do not care which intermediary bank to use, other customers may have an existing relationship with a particular bank through which the customer wishes to pass the transaction as an intermediary. If these fields are left blank by the customer (the customer does not care which bank is the intermediary). The bank uses the trusted intermediary bank in the transaction. A key 354 associated with coresponsondencecharge Charge indicates the party responsible for paying the intermediary bank fees (remittance or beneficiary).

FIG. 3E shows payment instruction display panel 302 when a user has selected payment details table 360. A display panel associated with this table allows the user to enter details of the payments reflected in the FTT. These fields can be used by the customer as the memo fields in checks. Typically the customer should enter information such as a purchase order number or invoice or other content indicating the purpose of the transaction (see also field 368 described below in fig. 3F).

Fig. 3F shows the payment instruction display panel 302 when the user selects the additional information table 364. The display panel associated with this form allows the user to enter additional details about the transaction, which the user wants to see and which is attached by the bank. When having the information on the payment details form 360 described above, the information placed in this field by the user need not be financial for the transaction, but allows the customer the opportunity to provide additional information to the bank. The field 368 allows the customer to place his or her reference number therein, such as a purchase order number associated with payment to be made by the transaction.

Fig. 4A-4E show a sub-table display panel for the payment instruction display panel 302 for IAT and GIRO transactions. As seen in these figures, these types of payment methods are different from TLX transactions, which do not involve an intermediary party in the IAT or GIRO transaction. There is thus no table of intermediary parties included in the payment instruction display panel 302 as depicted in fig. 3A-3F. Similarly, FIGS. 5A-5D depict display panels associated with tables in the Payment order display panel 302 for a money order or check transaction. In these types of transactions, the bank that benefits is not involved, so there is no display panel of lists to enter data for this bank.

Fig. 6A-6C reflect a sub-table display of the payment instruction display panel 302 associated with notifying receipt of a transaction. Associated with such transactions are 3 panels, a summary 400, a debit account 402, and a debit bank 402. As shown in fig. 6B, debit account display panel 402 includes a field 404 for entering a debit and a field 406 for a debit address. The display panel 402 also includes a customer reference field 408, as described above. Fig. 6C shows a debit bank display panel 410 which includes a field 412 for the debit bank name and a field 414 for its address. Debit accounts and debit banks are accounts and banks from which a bank customer wishes to properly pay.

FIGS. 7A-7E illustrate exemplary screens for a customer to add a transaction using repeat lines. The specific example depicted in these figures relates to a multi-currency/multi-bank debit transaction. As seen in fig. 7A, the account 306 is named in dollars, while the transaction is conducted in german mark. The basic Add screen for adding repeat transactions is the same as that used for free format Add repeat transactions, namely, settlement information display panel 300, transaction quantity display panel 324, and payment instruction display panel 302 and its associated sub-display panels.

To enter a repeat transaction, the customer either types a repeat Line number in the Line # combo box 304 or clicks the Line # button 500. If the user clicks the Line # button 500, a straight Line grid is displayed that includes, in summary form, all of the lines that the user uses to set up a transaction. The list of repeated rows is displayed according to the user's rights. The data columns displayed in the lookup window of this row are payment method, customer row number, account number, final beneficiary name, final beneficiary Id, intermediate party name, Pay/Rec (Pay or receive). The rows can be sorted (ascending/descending) by data column.

When the user selects a repeat line number, either directly via keypad entry or via display list entry, the transaction associated with that line will be displayed in the remaining data fields (e.g., account number, bank ID). Some of the repeated rows will contain only certain fields of transaction data and the user must enter the remaining data on the settlement information display panel 300. For example, a repeat row may contain all transaction data, except for the transaction amount, the date of the event, and any additional memo data that the user wishes to place in the additional information table 364.

By clicking on the accounts button 306, the user may see a list of accounts that are pre-established as being allowed to participate in transactions associated with the selected repeat line. Essentially, all accounts that the user has organic are screened for selected repeat lines. In this manner, the user is able to select a particular account related to the transaction without the need to enter the remaining data fields from the keypad. The concept of screening also works in reverse. The user can click on the accounts button 306 to select an account, and when he clicks on the Line # button 500, the user can see the filtered list touching the repeat lines used with the selected account. Similar screens exist for the type of settlement and the payment method.

The remaining fields appearing on the settlement information display panel 300 are the same as previously described with respect to the free-format transaction with reference to fig. 3A. All fields in the settlement information display panel 300 must be filled so that the user processes the transfer data display panel 324. The transaction amount display panel 324, in turn, allows the customer to enter a date of interest and the number of repeat transactions. The currency of the transaction is read-only and cannot be changed.

As previously described, the user can call up a calendar to enter a date. The calendar will not display any holiday information, but when the transaction is stored, the present invention checks the rest-on date against background business processes and transaction currencies to determine the effect of any holiday. This check is based on whether it is a holiday in the country where the cash is paid and whether the debit account owed to the branch/background service is in a holiday.

As shown in fig. 7A-7E, the payment instruction display panel 302 for the debit transaction includes a summary display panel 502 (fig. 7A), a debit account display panel 504 (fig. 7B), a debit bank display panel 506 (fig. 7C), a payment details display panel 508 (fig. 7D) and an additional information display panel 510. When repeating line-add transactions are used, the data is predetermined for virtually all fields included on these display panels. One exception is at payment details display panel 508 (fig. 7D), where the customer can enter information indicating the purpose of the transaction or other user needs, as previously described.

Once the user is satisfied with the entered transaction (whether by freeform or by repeat lines), the user can click on the store button 512 (FIG. 7A) to store the transaction. The store transaction serves as a store transaction but does not release it (execute it). During the storage, FTT is digitally signed using conventional security means in order to validate the transaction. Once the transaction is stored, it can be approved, modified, deleted or released. Most customers for online transactions have an internal organization to approve and release the transaction. Typically, one person has authorization to approve a transaction, while another person has authorization to release the transaction. These different authorizations are built into the rights database described above.

Transactions that have been entered can be approved, modified or deleted. Any user with the appropriate privileges can delete a transaction by selecting it on the summary display panel 200 (see fig. 2) and clicking the delete key. The system needs to confirm this deletion. To approve a transaction, the user selects one or more FTTs from summary screen 200 (see FIG. 2) with input status. The user then clicks the ok key 210. The system then verifies the digital signature of the approved FTT during the addition or modification process to verify the authenticity of the transaction. Once verified, the state of the FTT is changed to approved and the system updates this summary screen 200. Once an FTT is approved, it can be released, deleted or further modified. If a duplicate row is used to establish the FTT, and if the duplicate row is later changed, the system prompts the user for approval of the details of the new row. Approved transactions may be deleted as previously described.

An entered or approved transaction can be modified. To modify a transaction, the user selects one or more FTTs from summary screen 200 (see FIG. 2). The user then clicks the modify button 230. The user then makes changes in the settlement information display panel 300, the transfer amount display panel 324, and the payment details display panel 508 (see fig. 3A). For repeated transactions, the user may only modify the expiration date, amount and payment details. If the user wants to make other modifications to a repeat transaction, the user must add a new transaction. When the modification is finished, the user stores the transaction, which then has the input status, as a new transaction. Once the transaction is modified, it must be approved before being released.

To release a transaction, the user selects one or more FTTs with an approval status from the summary screen (see FIG. 2). Transactions with an approval can be released and transactions with past expiration dates cannot be released. The user then clicks the release key 240. The system then prompts the user for a password. If the password is received, the system then verifies the digital signature and digital authenticity of the FTT to be released and releases them to the bank's back-office processing system 16, 32 (see FIG. 1) for processing. The user will be informed of FTTs for which the digital signature is invalid or the rights limits are not met (e.g., the number of transactions exceeds a predetermined limit within the rights range). Once a transaction is released to the bank's back-end business processing system 16, 20, its state changes to pending. When a control number occurs at the bank's back-end transaction system 16, 20, the state of the FTT changes to release. This control number is used by customers and banks to track the status of this FTT through the SWIFT system and the funds transfer system 22 (see fig. 1) of other banks.

As described above, a customer may conduct a transfer of funds from a second bank to a third bank through one bank using the online transfer device of the present invention. Funds do not have to be sent from the bank in which the host system of the present invention is installed. For example, if bank A is the host of the system, the customer can log into the system at bank A and establish an FTT that transfers funds from the customer's account at bank B to the account at bank C. To accomplish this, the transaction, once established, approved and released, proceeds from bank A's funds transfer system 20 (see FIG. 1) to bank B's funds transfer system, which processes the FTT by transferring funds to the designated bank C's account. If the customer previously arranged bank B to receive an electronic transfer instruction (SWIFT information) from bank a, bank B will honor the FTT. In this manner, a single customer can use a single simple interface of the present invention to accomplish all online needs without all the difficulties of going up to have to communicate with all the banks holding accounts.

Another important function of the present invention is the cash extreme function. This part of the system allows the details of any account he owns to be seen through the use of the internet and the single component interface of the present invention. The cash statement function of the present invention, because of the online start function, has the advantage that customers do not have to establish separate communications with their respective banks, maintain separate software packages, remember separate user ids/passwords, process various security devices, pay separate software usage fees, learn to use different transaction input screens, and process separate transaction databases without the inefficiencies of separate transaction databases.

A main screen 600 for the cash statement display is shown in fig. 8. Area 602 displays a list of all reports that the user can manipulate. Although it is envisioned that any type of report could be generated, there are eight different reports in the preferred embodiment of the present invention, including. Simply balancing the account statement; a balanced accounts and transaction summary statement that summarizes transactions over a selected time period; an average account and transaction detail statement including transaction details over a selected time period; check for payment in ascending U.S. Dollar order (Checks payment acceptance wallar); checks for payment in descending dollar order (Checks Paid DespendingDollar); controlling the expenditure amount of funds; lock box (Lock box) details; lock box summary.

In area 604, the customer selects a time-related box for reporting. If the customer selects the circular button priority 606, the time frame for this report is counted from the previous one. Selection of the circle button Current 608 causes the statement to include balanced accounts and/or activities from the Current day, while the circle button Last Access 610 generates a statement from the date the customer previously operated the statement. The text behind circle button 606 and 610 allows the user to see the date of the information included in the report, while the Calendar button allows the user to quickly select the date. Calendar button 612 is also required for even single day reports, allowing the customer to make time zone adjustments while operating globally.

As an alternative to the Prior, Current and Last reports, the customer may select the circular button 614 for generating a user defined date range report. The user enters the desired Date Range into the From and To text boxes that appear under the Date Range circular key. Again, a calendar button 616 is included to allow the customer to quickly select a date. The selection of the date range is applicable to all reports.

The account from which the customer can generate a report is listed in area 618 of the screen. The account is identified by an account number, account name, bank identifier, branch number, and country in which the bank is located. The rights database contains a list of accounts that a particular user is allowed to see. Only accounts that the user has authority are listed in area 618. Although in the example depicted in fig. 8, area 618 lists accounts from only one bank, Chase Manhattan, the user can see details from any of its accounts at other banks, as long as the other banks provide account information to the host of the present invention.

Referring to fig. 1, the present invention provides a connection from the host's bank's information reporting system 24 to the reporting system 18 of any other bank with the customer's specific account. Through this link, the other banks provide files including the customer's account information to the host bank's reporting system 24. The customer must have previously requested and authorized other banks to provide this information to the bank where the host is located. Data from other banks is reformatted in the information reporting system 24 to be consistent with data from the primary accounts included in the reporting system 24. As described above, an important aspect of the cash reporting feature of the present invention is that it provides the customer with a consistent user interface and reporting regardless of the source of the account data.

Check block 620 allows the customer to select the account from which the report is generated. Once the user selects the account, he can select the Run Report button 622 to generate a Report and the View Report button 624 to View the Report. The View Report button 624 will provide the user with a list of reports that have been run and stored within the last 5 days, which can be seen by the user. Mark Account button 626 allows the user to select all accounts listed in field 618, while Clear Account clears all accounts selected by the user.

Fig. 9A through 13 illustrate examples of some account reports produced by the present invention. Figures 9A-9D illustrate a balanced accounts and transaction detail report for the current day (the day the report is run). This report includes details of all transactions processed (not necessarily posted) during the current day. As seen in fig. 9A, the report includes a transaction date 700 for a given account number. The portion 702 of the report includes a summary of the account activity, while the credit report for the account begins at point 704 in the report. The entries included at the bottom of FIG. 9A to FIG. 9C are details regarding the account deposit transaction. The total credit to this account is made at 706 in FIG. 9C. Statement 2 of loan transaction 708 of figure 9C begins and continues to the bottom of figure 9D. The total debits for the account are listed at 710 at the bottom of figure 9D. Thus, this report gives the customer a detailed representation of all activities on the current day for the listed accounts.

10A-10G provide similar balanced accounting and transaction details for activities on previous days, except that these figures include account details for two different accounts on the same statement. Fig. 10A-10C show details of a previous japanese transaction for one account 720, while fig. 10D-10G show details for a second account 722 (see fig. 10D). It is thus clearly shown that the present invention is able to produce detailed account activity in a single report on several accounts from several different banks. Although not shown, a similar balanced account and transaction detail report can be generated for LastAccess and Data Range time periods.

11A-11C illustrate exemplary summary reports generated by the present invention. The time frame for this particular report is from Last Access by the customer. Similar to the detailed reports described above, the summary report includes a summary section 730 that integrates the credits and debits to/from the account. Beginning in section 732, each storage transaction is listed in a summary format, different from the detailed format shown in fig. 9 and 10. The loan summary begins at 734 in FIG. 11B. This summary format provides the customer with a list of all transactions but no detailed information included in other reports, and the detailed reports can be run if the customer needs to see the detailed information of the transactions when reviewing the summary report. In section 736, the summary report ends with a complete summary that balances the account, total deposit, and total loan. Although not shown, similar summary reports can be generated within the time frame for Prior, Current and Data Range.

Fig. 12 shows a balanced accounts report for a previous day. This report, when used with the previously described report, does not include any transaction details. For other reports, a balanced account can be generated for the Current, last Access and DataRange time frames. FIG. 13 is a report generated with respect to Demand deposit Account (DDA-Demand deposit Account). This report lists details about the account activity, i.e., the checks that were posted to that account. This particular statement lists the checks in descending order. A separate report (not shown) lists the checks in ascending order.

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

Claims (29)

1. A system for receiving and processing funds transfer transactions from customers of a financial institution, said system comprising:

an application server having an internet application, wherein a customer of the financial institution can access the internet application through a standard internet browser;

a plurality of user input screens contained in an application on the internet, said user input screens receiving input from a customer regarding at least one funds transfer transaction;

a back-end service processor connected to the application server, said back-end service processor receiving information from the application server, generating funds transfer instructions in response to the received input information and executing said funds transfer instructions.

2. The system according to claim 1, wherein the financial institution is a first financial institution and wherein the at least one funds transfer transaction involves transferring funds from a first account at the first financial institution to a second account at a second financial institution, the system further comprising:

a connection between the first financial institution and the second financial institution, wherein the back-office processor executes the funds transfer instructions by transferring funds to the second financial institution.

3. The system according to claim 1, wherein the financial institution is a first financial institution, wherein at least one funds transfer transaction involves transferring funds from a first account at a second financial institution to a second account at a third financial institution, the system further comprising:

a connection between a first financial institution and a second financial institution, wherein the back-office processor executes the funds transfer instructions by sending the funds transfer instructions to the second financial institution which in turn sends the funds to a third financial institution.

4. The system of claim 1, wherein said user input screen further comprises:

input fields for receiving a pointer to a repeat line and a quantity of a funds transfer transaction, said repeat line including predetermined details regarding said funds transfer transaction, wherein the back office processor generates funds transfer instructions using the repeat line and said quantity.

5. The system of claim 1, wherein said user input screen further comprises:

input fields for receiving the following items:

account information describing the debit account,

information describing the ultimate beneficiaries of the funds transfer transaction,

final benefit bank information describing the bank that ultimately benefits the funds transfer transaction,

intermediate bank information describing an intermediate bank involved in the funds transfer transaction, and

payment detail information describing details about the customer involved in the funds transfer transaction.

6. The system according to claim 5, wherein the application server deposits and stores the input information as repeat lines, wherein the repeat lines may be used for subsequent funds transfer transactions.

7. The system of claim 1, wherein the funds transfer transaction requires transfer of funds from a first account of the financial institution to a second account of the financial institution, the back office processor performing the funds transfer by transferring funds from the first account to the second account.

8. The system of claim 1, wherein the funds transfer transaction requires the transfer of funds from a first account to a second account, and wherein the accounts are of two different currencies.

9. The system of claim 1, wherein the internet-based application further comprises a reporting application, the reporting application allowing a customer to generate and view reports regarding the customer's account.

10. The system of claim 9, wherein the customer's account includes the customer's account at the financial institution and the customer's account at another financial institution.

11. The system of claim 9, wherein the report includes a report regarding balance accounts for the account, a report regarding transactions conducted by the account, a control payment funds report, and a lockbox report.

12. The system of claim 1, wherein the internet application further comprises a security application that verifies the customer's authorization to enter, modify, approve and release funds transfer transactions.

13. The system of claim 12, wherein the security application authenticates the funds transfer transaction.

14. The system according to claim 12, wherein the customers are a plurality of users, and wherein the security application verifies the user's authorization to enter, modify, approve and release funds transfer transactions.

15. A method for receiving and processing funds transfer transactions from a customer of a financial institution, said method comprising the steps of:

providing secure access to applications on the internet through a standard internet browser;

receiving input information from a customer via a user input screen of the on-internet application, the input information relating to at least one funds transfer transaction;

generating a funds transfer instruction in response to the received input signal; and is

Executing the funds transfer instructions.

16. The method of claim 15, wherein the financial institution is a first financial institution, the method further comprising the step of transferring funds from a first account of the first financial institution to a second account of a second financial institution.

17. The method according to claim 15, wherein the financial institution is a first financial institution, and wherein the step of executing funds transfer instructions further comprises the steps of:

a transfer of funds from a first account at a second financial institution to a second account at a third financial institution.

18. The method of claim 15, wherein the step of receiving input information from the customer further comprises the steps of:

receiving a pointer to a repeat row, wherein the repeat row contains predetermined details relating to the funds transfer transaction; and is

Receiving the amount of the funds transfer transaction, wherein the funds transfer instructions were generated using the repeat lines and amounts.

19. The method of claim 15, wherein the step of receiving input information from the customer further comprises the steps of:

receiving account information describing a debit account;

receiving end beneficiary information describing end beneficiaries of the funds transfer transaction;

receiving information describing a bank's ultimate benefit of the funds transfer transaction;

receiving intermediate bank information describing an intermediate bank involved in the funds transfer transaction; and

payment detail information describing details about a customer involved in a funds transfer transaction is received.

20. The method of claim 19, further comprising the steps of:

storing the input information as repeated lines; and is

The stored repeat lines are used in at least one subsequent funds transfer transaction.

21. The method according to claim 15, wherein the step of executing funds transfer instructions comprises the step of transferring funds from a first account of the financial institution to a second account of the financial institution.

22. The method of claim 15 wherein the step of executing funds transfer instructions further comprises transferring funds from a first account in a first currency to a second account in a second currency.

23. The method of claim 14, further comprising the step of generating a report on the customer account.

24. The method of claim 23, wherein said customer accounts include customer accounts at said financial institution and customer accounts at another financial institution.

25. The method of claim 23, wherein the step of generating a report further comprises the steps of:

generating a statement regarding a balanced account for the account;

generating a report on transactions conducted with respect to said account;

generating a report on controlling the payment funds; and

a report is generated regarding the lockbox operation of the customer.

26. The method of claim 15, further comprising verifying the customer's authorization to enter, modify, approve and release funds transfer transactions.

27. The method of claim 15, further comprising the step of authenticating the funds transfer transaction.

28. The method according to claim 12, wherein the customer has a plurality of users, the method verifying the user's authorization to enter, modify, approve and release funds transfer transactions.

29. The method of claim 28, wherein the plurality of users have different authorizations.