Electronic banking system

• US 20060112011A1
• Filed: 09/16/2003
• Published: 05/25/2006
• Est. Priority Date: 09/16/2002
• Status: Abandoned Application

• Current Assignee: Saudi Arabian Oil Company (Government of Saudi Arabia)
• Original Assignee: Saudi Arabian Oil Company (Government of Saudi Arabia)
• Inventors: Al-Ali, Abdulhadi M
• Application Number:
  US10/521,499
• Publication Number:
  US 20060112011A1
• Time in Patent Office: Days
• US Class Current: 705/42
• CPC Class Codes: G06Q 20/04 Payment circuits
• CPC Class Codes: G06Q 20/10 specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
• CPC Class Codes: G06Q 20/108 Remote banking, e.g. home banking
• CPC Class Codes: G06Q 40/02 Banking, e.g. interest calculation or account maintenance credit or loans G06Q40/03

Abstract

An automated electronic banking system for initiating and automatically processing monetary transactions, includes initiating means for maintaining a transaction record and permitting a remotely located customer of a bank to selectively initiate a monetary transaction request for automated processing, a bank host server adapted for automatically receiving and processing the monetary transaction request, a computer network in data communication between the bank host server means and the initiating means, for transmitting the payment transaction request from the customer'"'"'s initiating means to the to bank host server, and interface means located between the initiating means and the computer network for automatically interfacing the initiating means to the bank host server, and for converting the monetary transaction request into a readable form compatible with the bank host server, wherein the customer'"'"'s initiating means periodically receives in response from the bank host server confirmation data for permitting the initiating means to automatically reconcile the transaction record on a daily basis. The present invention is further directed to a method for an automatic electronic banking system for permitting a customer of a bank to remotely authorize and request a computerized monetary transaction to be made by their bank.

Claims

1. A method for an automated banking system for permitting a customer of a bank to remotely authorize and request a computerized monetary transaction be made by their bank, said method comprising the steps of:

providing a computerized system at the customer'"'"'s location;

receiving on the customer'"'"'s system, a customer'"'"'s manually inputted request for the customer'"'"'s bank to conduct a monetary transaction;

automatically running on the customer'"'"'s system, in response to a request, a monetary transaction program for generating a properly formatted monetary transaction document as an intermediary document (IDOC);

automatically retaining in the customers system the IDOC in a remote function call (RFC) queue, for a predetermined period of time, to permit the IDOC to be passed into an eBanking interface server of the customers system for further processing;

programming said interface server to automatically convert the IDOC into an extensible markup language (XML) formatted document;

automatically transferring over a computer network the XML formatted IDOC from the customer'"'"'s system to a compatible eBanking server in the customer'"'"'s bank; and

automatically processing the requested monetary transaction via said server of said bank responding to the IDOC.

2. The method of claim 1, further including the steps of:

automatically operating the bank'"'"'s eBanking server to send an XML formatted status document to said customer;

automatically receiving said status document on the customer'"'"'s system;

operating the customer'"'"'s system to permit the customer to read the received status document; and

automatically logging the received status document into a core transaction database memory in the customer'"'"'s system.

3. The method of claim 1, wherein said step of automatically running said monetary transaction program includes the steps of:

entering parameters for the requested monetary transaction;

creating a monetary transaction proposal; and

executing a monetary transaction run to generate said IDOC.

4. The method of claim 1, wherein said RFC queue retaining step includes the steps of:

releasing the IDOC to the RFC destination of the eBanking server in the customer'"'"'s bank;

updating the IDOC status to a digitized code indicative of data being successfully passed to a port;

executing the IDOC received at the port into an RFC queue; and

checking to determine if a communication link to said server in the customer'"'"'s bank is active or inactive.

5. The method of claim 4, further including the steps of:

responding to said interface server of said bank being inactive by increasing a number of retries counter by “

1”

;

determining if the number of retries is greater than a predetermined maximum number; and

resubmitting the IDOC to the RFC queue if the number of retries does not exceed the maximum number; and

a repeating said checking step.

6. The method of claim 5, further including the steps of:

responding to the number of retries being greater than the predetermined number, by notifying troubleshooting personnel of a problem in establishing a communication link with said interface server of the bank;

resubmitting the IDOC to the RFC queue in response to a communication that the linkage problem has been resolved; and

repeating said checking step.

7. The method of claim 4, further including the steps of:

responding to an active interface server by mapping the IDOC parameter fields to appropriate variables;

storing IDOC data in an eBanking DB (database);

updating the IDOC status to indicate acceptable translation;

formatting the IDOC into instructions complying with a standard format implemented by the Society for Worldwide Data Bank Communication;

compiling the formatted IDOC and subsequent formatted IDOCs each into a transaction document formatted in extensible markup language (XML);

retrieving bank specific parameters from an eBanking.CNF configuration file;

creating a digital signature for each XML formatted document using client certificates;

establishing a secure connection to the computer server in the customer'"'"'s bank;

determining whether a secure connection was successfully established; and

responding to a successfully established secure connection by transferring over a computer network each transaction document containing transaction instructions and a digital signature to the computer server in the customer'"'"'s bank.

8. The method of claim 7, further including the steps of:

responding to a failure to establish a secure connection by logging the XML document along with bank specific parameters into a database labeled “

Failed Services”

;

automatically retrying the successive steps of creating a digital signature, establishing a secure connection, and determining if a secure connection has been established;

determining whether the number of retries is greater than a predetermined maximum number; and

continuing said step of automatically retrying if the number of retries is not greater than the maximum number.

9. The method of claim 8, further including the steps of:

responding to the number of retries exceeding the maximum number, by updating the IDOC status to a code indicative of an error while posting payments;

sending an e-mail notification to an authorized officer of customer for release of the payment via prior conventionally established telex or facsimile transmission;

responding to the e-mail, the authorized officer releases or provides the monetary transaction documents via telex or facsimile to the bank; and

updating an IDOC status code to indicate the monetary transaction successful completion has been acknowledged by the bank.

10. The method of claim 7, further including the steps of:

waiting for a response over the computer network from the bank;

receiving from the bank a response document formatted in XML containing response status codes and messages for each of the monetary payment instructions posted to the customer'"'"'s bank;

storing in an eBanking database the response document;

processing the statuses in the response document for each of the associated monetary transactions instructions; and

determining the status from the bank of each monetary transaction.

11. The method claim 10, wherein the step of determining the status of each monetary transaction includes the steps of:

indicating a status code equivalent to “

OK”

for monetary transactions successfully processed by the bank; and

updating related IDOC statuses to have a code indicative of the bank having advised the monetary transaction was successfully made.

12. The method of claim 10, further including the steps of:

indicating a status code corresponding to a Data Error causing the bank to reject the monetary transaction; and

updating the IDOC status for the transaction to a code indicative of the transaction rejection due to a Data Error.

13. The method of claim 12, further including the steps of:

sending an e-mail notification to an authorized officer of customer indicating the reason for rejection of the monetary transaction;

determining by action of the authorized officer whether the rejection is valid;

responding to a valid rejection by action of the authorized officer to use an eBanking transaction request to reverse the monetary transaction request;

correcting via action of the authorized officer, the data that caused the bank to reject the monetary transaction; and

reprocessing the corrected monetary transaction through said banking system for completion.

14. The method of claim 13, further including the steps of:

responding to an invalid rejection by action of the authorized officer using appropriate eBanking transaction codes for releasing the monetary transaction via tested telex transmission to the bank; and

receiving via the customer'"'"'s computer system an acknowledgment from the bank confirming completion of the monetary transaction.

15. The method of claim 10, further including the steps of:

indicating a status code corresponding to “

Failed”

for the bank failing to complete the monetary transaction for unknown reasons; and

updating in response to the “

Failed”

code the IDOC status to a code indicative of the failed monetary transaction.

16. The method of claim 15, further including the steps of:

sending via e-mail notification from the bank to the authorized officer the reasons for the failure by the bank to complete the monetary transaction;

releasing by action of the authorized officer using an appropriate eBanking transaction code via tested telex or facsimile authorization to the bank to complete the monetary transaction; and

receiving via telex or facsimile from the bank to the customer confirmation that the monetary transaction was completed.

17. The method of claim 10, further including the steps of:

indicating from the bank either a return status code corresponding to “

DUDE”

for a duplicate transmission by eBanking of a previous transmission rejected by the bank due to a Data Error, or corresponding to “

DUOK”

for a duplicate transmission by eBanking of a previous transmission successfully processed by the bank;

determining via the customer'"'"'s computer system whether the return status code corresponds to DUDE or DUOK;

determining in response to a status code of DUDE whether the last IDOC status for the monetary transaction is indicative of the transaction being rejected by the bank due to a Data Error;

sending, in response to a rejection due to a Data Error, an e-mail notification to technical personnel for troubleshooting the reasons the monetary transaction was posted in duplicate to the bank; and

sending, in response to a rejection not being due to a Data Error, an e-mail notification to an authorized officer of customer to indicate reasons monetary transaction was rejected by bank.

18. The method of claim 17, further including the steps of:

determining in response to a status code of “

DUOK”

whether the last IDOC status for the monetary transaction is indicative of successful processing of the transaction by the bank;

changing the IDOC status to a code indicative of successful processing, in response to a No answer in the immediately previous determining step; and

sending an e-mail notification to an authorized officer of customer and customer'"'"'s technical personnel, in response to a Yes answer in the previous associated determining step, for indicating the monetary transaction was duplicated in said automated banking system.

19. The method of claim 1, further including the steps of:

initiating, by action of the customer using a scheduler, a request for a bank statement;

passing the request to said interface server of customer for conversion into an XML document;

retrieving required parameters from an eBanking configuration file necessary to establish a secure socket layer (SSL) session over said computer network;

establishing over said computer network a secure connection to the bank'"'"'s eBanking server;

determining if the connection is successfully established;

determining in response to an unsuccessful connection whether a number of retries is greater than an allowed maximum number;

repeating said secure connection establishing step in response to the number of retries not exceeding the maximum number;

sending an e-mail, in response to the number of retries exceeding the maximum number, to an officer of customer and technical personnel to advise of the connection or statement retrieval failure; and

raising a “

Failure”

exception to the scheduler for permitting a manual request for the statement.

20. The method of claim 19, further including the steps of

responding to a successful connection in said secure connection establishing step by posting the XML document containing statement request parameters to the bank'"'"'s eBanking server;

retrieving on customers system statement(s) in XML formatted responses from the bank;

storing both the XML formatted request(s), and response(s), in an eBanking database of the customer,

retrieving the statement(s) from the eBanking database to create a file in a designated folder; and

reconciling the statements through use of standardized banking business software.

21. The method of claim 1, further including the steps of:

initiating by action of the customer using an eBanking transaction code for requesting a statement showing the completed monetary transaction(s);

converting, via said interface server of customer, the request into an XML formatted document;

retrieving required parameters from an eBanking configuration file necessary to establish a secure connection over the computer network to an eBanking server of the bank;

establishing over said computer network a secure connection to the bank'"'"'s eBanking server;

determining if the connection is successfully established; and

responding to the unsuccessful establishment of the connection by returning a connection error message for display to the customer.

22. The method of claim 21, further including the steps of:

responding to the successful establishment of the connection by posting to the eBanking server of the bank the XML document containing the statement request parameters;

receiving on the eBanking interface server of the customer a response from the bank of an XML formatted statement; and

extracting the statement(s) for display to the customer.

23. An automated electronic banking system for initiating and automatically

processing monetary transactions, said system comprising:

initiating means for permitting a remotely located customer of a bank to selectively initiate a monetary transaction request for automated processing;

a bank host server adapted for automatically receiving and processing said monetary transaction request;

a computer network in data communication between said bank host server means and said initiating means, for transmitting the payment transaction request from the customer'"'"'s initiating means to the bank host server; and

interface means located between said initiating means and said computer network, for automatically interfacing the initiating means to the bank host server, and for converting said monetary transaction request into a readable form compatible with the bank host server.

24. The system of claim 23, further including:

security means for establishing a secure transfer of data between said initiating means and said bank host server.

25. The system of claim 23, further including:

programming means for operating said initiating means, interfacing means, and bank host server to automatically respond to said monetary transaction request, whereby said bank host server completes the monetary transaction, and insures the production of all necessary electronic records detailing every necessary tracking step carried out in completing the payment transaction.

26. The system of claim 23, wherein said initiating means includes:

at least one computer for permitting a customer to generate said monetary transaction request;

a local computer server of customer connected between said at least one computer and said interfacing means; and

a core transaction database memory for storing necessary computer programs for operating said local computer server, to respond to customer'"'"'s monetary transaction request by preparing a monetary transaction order in the form of intermediary documents (IDOC), and all necessary tracking records for various associated payment parameters.

27. The system of claim 26, wherein said interfacing means includes:

an interface computer server of customer connected between said local computer server and said computer network; and

a core interface database memory for storing necessary computer programs for operating said interface computer server to convert communications from said local computer server into a format for communication over said computer network, and for storing said IDOCs, transaction documents, return codes, and messages related to transactions with said bank host server means.