HRP20030164A2 - Multifunctional mobile banking system - Google Patents

Description

Field of invention

This invention relates to the field of integrated transaction platform systems for multifunctional mobile banking systems.

Background of the invention

There is a growing need for flexible, mobile, and user-friendly solutions for traditional transaction and data delivery systems. In no economic branch is the demand greater than in banking, financial services, and the electronic industry for transactions. Internet communications; high speeds, processing of large amounts of data; the exponential growth of technological advancements and customer initiatives to embrace new technologies are increasing the speed at which service industries must offer improved systems. Banking, financial services, and electronic transaction companies whose business is mainly collection, archiving, protection, and transfer of electronic financial data are particularly sensitive to these growing user demands.

Today, a number of overlapping systems are used to provide access to banking, financial services and electronic transactions. For example, banks and other financial institutions wishing to secure the transfer of funds between themselves using specific communication and security protocols may use Electronic Funds Transfer (EFT) protocols and encrypt communications and Personal Identification Numbers (PINs) using the Data Encryption Standard (DES). and may send such information over dedicated data lines or through telephone connections to privatized services or diverters. Credit and debit card companies can use a variety of communication protocols, encryption standards, and data transfer protocols to send transaction details between merchants and financial institutions, and other protocols for transactions between merchants and consumers (such as various point-of-sale systems (POS)) or transactions between consumers and financial institutions. Some banks and other financial service providers have developed their own solutions for financial services for customers and businesses over the Internet, through call systems for transactions and automatic teller machines (ATMs). Electronic commercial Internet businesses, Internet banks, and companies offering supporting electronic transactions have also developed their own specific data exchange protocols using standard Internet protocols and business-to-business (B2B) solutions. All these systems intertwine and influence each other.

The use of isolated or privatized communication systems and industry-specific or privatized protocols for data transfer and encryption offers an additional measure of security to institutions using such systems and protocols. However, in doing so, some institutions have compromised their ability to easily integrate these systems with increasingly prevalent protocols, such as those used on the Internet. Further, many of these solutions are outdated and difficult for advanced modifications in technology and additional service requirements. In addition, various software and hardware providers serve the financial services industry and promote privatized and incompatible solutions that can be difficult for further improvements in communication and data processing systems and growing user demands.

The advent of modular programming, hardware-independent programming platforms (eg, Enterprise Java Beans and Java Beans Enterprise Application Servers), server/detached client applications, and non-parallel global data transfer networks (the Internet) have laid the foundation for implementing a multifunctional transaction management system. for banking and other financial services. Additionally, no system has integrated all of these tools to provide a flexible, extensible, easy-to-use, and reliable system.

These and other disadvantages of the previously mentioned systems are overcome by various solutions of the present invention.

Content of the invention

Therefore, the object of the invention is to overcome the aforementioned disadvantages of the previous systems.

An additional object of the invention is to provide a system and method for enhanced banking services through a wide variety of service endpoints.

Additional objects and advantages of the invention will be set forth in part in the description that follows and in part will be apparent from the description, or may be realized by use of the invention.

These other objects of the accepted solution are achieved by an integrated transaction management system containing one or more user servers, financial data gateways, and a number of modular financial server applications. User servers provide interfaces for various wireless and Internet devices. For example, customer servers support Web-based Automated Teller Machines (ATMs), Point-of-Sale (POS) devices, Electronic Funds Transfer (EFT) access devices, Internet and telephone banking, wireless short message services (SMS), and wireless application protocols (WAP). ) devices, and other devices of the separated client. The financial data gateway provides communications and transactions with various financial data networks using various communication protocols. Modular financial services applications can be hardware platform independent and easily adoptable and extensible. Some examples of such modular financial services applications include offering account access, account management and maintenance, automated transaction management, event messaging, and account and card-based transactions for goods and services. Communication with the universal register of account and card data facilitates additional transaction security and extended customer service through an integrated transaction management system.

The accompanying drawings, which are attached and form a part of this specification, illustrate the solution of the invention and, together with the description, serve to explain the principle of the invention.

Brief description of the drawing

Figure 1 is a schematic representation of an integrated transaction management system that offers banking services according to the solution of the present invention.

Figure 2 is a schematic representation of a modular system for processing user service requests according to the solution of this invention.

Figure 3 is a schematic representation of an integrated transaction management system for managing various banking service transactions through various end point services according to the solution of this invention.

Figure 4 is a flow diagram illustrating a method of providing an event messaging application over an integrated transaction management system.

Detailed description of the solution

The references of the accepted solution of the invention will now be presented in detail, examples of which are presented in the accompanying drawings in which the reference marks refer to the corresponding elements.

Referring generally to the drawings, and to Figure 1 in particular, an integrated transaction management system 100 for providing financial and other services is shown. The integrated transaction management system 100 includes a Communication Gateway 110 and an Application Server 120 that both act as intermediaries between a number of financial institutions, such as banks 141 and 142, and a plurality of server interfaces 130, such as a Web Server 131, SMS Server 132, WAP Server 133, and ATM Server 134. Each type of server interface 130 allows the user to access a variety of banking services through various service endpoints, such as personal digital assistants (PDAs), mobile phones, personal computers, laptops, telephones, fax machines, ATM , POS systems and other devices. Each of the exposed server interfaces 130 supports different communication protocols and interface standards to enable one or more types of service endpoints or terminal devices to communicate with a variety of financial institutions. Application Server 120, in communication with interface servers 130, contains a number of modular applications for providing a large number of banking services, such as a savings account, a checking account, credit cards, debit cards, access to brokerage accounts and administrative services, automatic transaction management systems , service of event messages, service of transactions of goods and services, and other similar banking systems. In one solution, the Application Server 120 can be connected to the Cryptographic System 121 to provide increased security of communications. Application Server 120 may manage communications related to customer banking services, such as account balance inquiries, electronic fund transfers, and other transactions with external financial institutions, through Communications Gateway 110. Communications Gateway 110 functions to properly route or direct communications to a or more financial institutions, such as banks 141 and 142, over one or more communication networks. External data stores, such as data store 150, contain personal account information of multiple users, thus enabling additional banking services to be available to users. A number of privatized terminal devices, such as ATMs 161 and 163 and POS system 162 may also be added to the integrated transaction management system 100.

In order to route communications, as noted above, Communications Gateway 110 contains hardware for switching and monitoring and software for managing communications related to user banking systems (such as electronic financial data) to predetermined destinations (financial institutions) according to communications protocols corresponding to those financial institutions. Communication Gateway 110 further includes a hub for routing traffic in electronic financial data between various otherwise disparate communication networks and financial data systems. Communication Gateway 110 may also include a variety of communication channels and networks for communicating electronic financial data using electronic funds transfer (EFT) standards, Internet-based standards, privatized standards, and other secure data transfer standards. For example, communication channels 141 a and 142 a may be standard EFT data transfer lines to and from any financial institution, such as banks 141 and 142 , connected to an international EFT network. Or, alternatively, the Communication Gateway 110 may provide other types of communication channels to financial institutions thus enabling a wider scope, or greater variety or efficiency of data exchange. For example, communication channel 141b can be set up as a B2B connection using Internet protocols (eg, TCP/IP), or a dedicated line or connection to a privatized banking server.

The communication pass 110 also serves to ensure communication with a number of data sources that contain outdated data from various banks or financial institutions. As shown in Figure 1, the Communication Gateway 110 can be connected to the data store 150 via the Communication Channel 150a. Communication Gateway 110 also supports a variety of communication protocols for sending and receiving data from a variety of data storage and processing resources interconnected using wide area networks, such as the Internet. The communication channels of the Communication Gateway 110 also serve to interconnect a number of specialized financial service endpoints. For example, communication channel 161a connects Communication Gateway 110 to ATM 161 and Communication channel 162a connects Communication Gateway 110 to POS system 162 .

Communication Gateway 110 can also communicate via TCP/IP protocol with one or more financial service application systems, each of which offers the user a range of financial services and/or financial service monitoring, reporting, and analysis for financial institutions. One example of such a financial service application system is Application Server 120.

In order to perform the aforementioned functions, the Communication Gateway 110 typically contains an AS/400 platform with an OS/400 operating system and ITM 2.2 software for accessing accounts and corresponding billing.

Application Server 120 contains one or more servers for setting up a number of financial service applications. Such financial service applications may include any service related to personal personalized banking, finance, money management, payment transactions or investments. Application Server 120 further contains a platform for launching applications for providing user financial services. Application Server 120 uses a modular application design that supports standard interfaces to provide a flexible, extensible, and largely hardware-independent system for providing financial service applications. For example, Application Server 120 may be an enterprise Application Server that offers a variety of applications that are composed of interchangeable application modules (eg, Enterprise JavaBeans). One such interchangeable Application Module may be used to enable Application Server 120 to offer financial services and respond to service requests from server interface 130. Another may enable Application Server 120 to initiate transactions (eg, transfers and requests) with external financial data providers. , such as banks 141 and 142 or data stores 150. In one solution, Application Server 120 may include a Microsoft NT 4.0 server running on a minimum 500 MHz CPU with at least 1-2 gigabytes of memory and running WebLogic software. In an alternative solution, the Application Server 120 may include a Microsoft NT 4.0 server 5 with a minimum 500 MHz CPU system with at least 0.5 to 1 gigabyte of memory and running Microsoft's SQL 7.0 or later software and with an array of SCSI disks and a RAID controller. Additionally, it should preferably include a number of network cards and a network capable of 100 megabits per second communication with other parts of the system.

Application Server 120 is connected to and communicates with Cryptographic System 121 to provide encryption and decryption services that are compatible with a variety of changing security standards used by financial service providers. For example, the Cryptographic System 121 may comprise a hardware cryptographic system that enables conversion between secure layer contact (SSL) or RSA encrypted account numbers and PINs on the one hand or DES-encrypted PIN blocks on the other. A hardware cryptographic system allows data encrypted in one standard to be decrypted from a first standard (eg, SSL, WSL, or SET) in hardware form and then encrypted in another standard (eg, DBS) from hardware form. In this way, the decrypted data is not available in an electronic or visible form that may be susceptible to accidental or intentional disclosures during the encryption process. Such strict data security protocols may be necessary to meet the data security requirements of one or more data security networks allowing one or more applications through Application Server 120, such as an international EFT network. Cryptographic System 121 may enable Application Server 120 to offer financial service applications through wireless or other Communication devices that are not equipped with an encryption standard that corresponds to specific security networks.

Interface servers 130, connected to Application Server 120, provide user interfaces for accessing one or more financial service applications hosted on Application Server 120. For example, Web Server 131 enables a series of dynamically generated hypertext markup language (HTML) documents to exchange with each other. information with the user. The user can access the Web Server 131 through any network device, such as a PC, WebTV, Personal Digital Assistant (PDA) or other Internet devices. HTML documents generated by Web Server 131 can be populated with content sent by one or more applications from Application Server 120.

The short message service (SMS) server 132 offers one or more short text messages for mutual information exchange with the user. The user can access the SMS Server 132 using any SMS device, such as a mobile phone, alphanumeric pager, or other wireless device with limited display capabilities. At least a portion of the content provided by SMS Server 132 may be sent to one or more applications from Application Server 120. Wireless Access Protocol (WAP) Server 133 may provide one or more interface pages, such as pages written in Wireless Markup Language (WML, extensible markup language (XML)), for mutual exchange of information with the user.

The WAP Server 133 can be accessed by a user using any device that supports WAP, such as a mobile phone, pager, two-way radio, smart phone, communicator, and some other wireless device. At least one part of the content that is available via the WAP Server 133 can be offered by one or more applications from the Application Server 120.

ATM Server 134 provides one or more interface screens for mutual exchange of information with a user via an automatic teller machine (ATM). ATM Server 134 may provide a series of HTML pages that can be accessed by a dedicated ATM client using client software (e.g., search software) and an Internet Communications Protocol (e.g., TCP/IP) similar to that used to access Web pages on World Wide Web. At least some of the content available through ATM Server 134 may be offered to one or more applications from Application Server 120. ATM Server 134 also provides an ATM interface that requires a privatized message format.

Banks 141 and 142 and Communication Channels 141a, 141b, and 142a may contain a variety of financial institutions and financial data networks. Banks 141 and 142 may be composed of a variety of traditional "brick and mortar" banks, Internet ("virtual") banks, savings and loan companies, credit unions, brokerage houses, loan companies, retail loan origination companies, mortgage companies, for service loans, collection companies, and other firms and institutions that maintain secure financial accounts and other information. The communication channels 141a, 141b, 142a may each be composed of any form of network connection, telephone network, dedicated fixed line, access network, LAN, WAN (eg, Internet), wireless communication network, and other similar network connection.

The data store 150 may contain any number of data stores that contain financial data or similar information. The data store 150 may be a localized data resource, such as a database or group of databases, or may be a distributed resource, such as a series of particular data distributed over a network. Communication channels 150a and 150b may comprise any type of network or path for data communication between two or more users. In one embodiment, data store 150 contains a store of financial account information and associated account access information, such as bank credit or credit card magnetic stripe information, for one or more users. Information related to a number of accounts offered by various financial institutions but belonging to the same user can be linked or localized for greater efficiency of access.

System 100 may include integrated service endpoints or terminal devices, such as an array of ATMs 161 and 163 and a POS system 162. ATM 161 may be a stand-alone ATM that contains its own application and interface software and is capable of exchanging data with one or more networks. financial data through the Communication Gateway 110. The POS system 162 can be a POS system integrated with a retail company, which contains its own application and interface software and which is capable of exchanging data with one or more financial networks through the Communication Gateway 110. The ATM 163 can be separated- an ATM client that uses, at least in part, Application Server Application Software 120 and ATM Server middleware 134. Other specialized client-side devices, such as a point-of-sale POS system, are also possible in conjunction with a compatible middleware server.

Figure 2 is a modular system 200 for processing a series of user service requests according to the solution of the invention presented. Modular system 200 can be used by an application server, such as Application Server 120 in Figure 1, to process a series of user service requests sent from user interfaces 130. Modular system 200 contains a series of Application Objects 210, such as Application Objects 211 and 212 Application Objects 211 and 212 are used as standard input paths for user service requests, such as from Users 201 and 202. Application Objects 211 and 212 make a transaction 220, such as Transactions 221 and 222, which describe what actions will be performed. . Router 230 evaluates Transactions 221 and 222 and sends them to the appropriate provider 240, such as Providers 241, 242, and 243. Providers 241, 242, and 243 contain operations to complete Transactions 221 and 222. In some cases, a provider, such as is Provider 243, may issue a Service Request 250 to access an external resource, such as financial data stored by a financial institution. Providers 241 , 242 , and 243 may either route transactions to the next service provider or may return a response 260 , such as Responses 261 and 262 , to Application Objects 211 and 212 .

Application Objects 210 provide standard input paths for user Service Requests 250 and initiate transactions 220 within modular system 200. Application Objects 210 represent individual callable actions of modular system 200. Some examples of Application Objects 210 may include an access object, an account balance request object, an account history request object, a transfer status object, an account detail request object, a customer service request object, and other objects to provide a range of financial, administrative, payment, and other services. In one solution, each Application object 210 is a declarative Enterprise JavaBean (EJB) and can be accessed by the user through the Java Naming and Addressing Interface (JNDI) (not shown). Each Application Object 210 creates a transaction 220 that describes the action to be performed and that contains the information about the user that is necessary to initiate the action. For example, an access Object is used to produce an access transaction that contains basic information such as a user's identity (eg, user's name, credit card number, ATM card number, etc.) and personal identification number (PIN). An account balance request transaction can be used to produce an account balance request transaction that contains the account number of that account (and preferably a username and PIN for security reasons). Each Application Object 210 may also call the Router 230 to determine the destination provider 240 that will process the transaction 220. In one solution, the Application Object 210 sends the transaction 220 to the Router 230 where the Router 230 evaluates the transaction 220 and sends it to the selected provider 240. Alternatively, the Router 230 may evaluate the transaction 220, but the Application Object 210 actually sends the transaction 220 to the selected provider 240 identified by the Router 230. Each Application Object 210 may also receive a request 260 from the provider 240 and pass a response 260 back to the user, such as users 201 and 202. Each Application Object 210 may also be capable of calling the provider 240 to cancel, redo, or modify the transaction 220 in response to a response 260, new user input, or other system conditions.

Transaction 220, such as Transactions 221 and 222, may contain data required by providers 240 to fulfill the function of Application Object 210. Transaction 220 may contain basic transaction information, such as a unique identifier, timestamp, status marker, originator, and destination (or provider list 240 to complete the transaction). Any amount of additional transaction-specific information may be appended to the transaction 220 as part of the data. In one solution, a piece of data contains one or more key/value pairs that provide a description of the data, such as an account number and PIN, and the data itself, for example, Account # 012345, PIN 9876. A piece of data can contain a wider range of data and forms and data format, such as a sequence of numbers, flags, strings, data, etc. Some examples of a Data Object may contain a graphic data of a canceled check, audio data of a voice recognition recording, or a spreadsheet of recent account transactions. The data may further contain a remittance containing data returned in response to previous transactions. In one solution, each transaction 220 is hosted as an XML document for access, evaluation, and modification by Router 230 and provider 240. In another solution, each transaction 220 contains complete transaction history data. Each transaction 220 can be automatically stored in the database and can be archived for later claims.

Router 230 determines the Provider 240 to perform transaction 220. Router 230 uses a combination of transaction details and/or system information to determine the optimal destination of Provider 240. For example, Router 230 may trace transaction data by account number, transaction volume, or username. Multiple Routers 230 may be used by the modular system 200 to perform such routing. An individual transaction 220 may be traced several times during its processing and the Router 230 may be used by the Provider 240 as well as by the Application Object 210. The Router 230 contains a trace table in an Extensible Markup Language (XML) document format that specifies conditions and/or rules according to which transaction 220 should be routed to a specific provider, such as one of Providers 241, 242, or 243.

Providers 241, 242, and 243 use modules that contain logic sets to perform at least a portion of the functions performed by one or more Application Objects 210. Such Providers 240 use data located within transaction 220 to perform each such function. The Providers 240 may return a response to the Application Object 210 that originated the transaction 220 or that may forward the transaction 220 to another Provider 240, with or without consulting the Router 230. The Provider 240 performs its functions locally using transaction data and local resources and system information and returns a response 261 to the Application Facility 210. Some Providers 240, such as Provider 242, may also perform their function(s) locally using transaction data and local resources and system information, but their function(s) may be only part of the complete function(s) requested. from Application Object 210. Transaction 220 may be modified to contain data generated by Provider 242 and may then be traced to another Provider 240, such as Provider 243. Some Providers 240, such as Provider 243, may trace all or part of data contained in transaction 220 to Service 250 and can then receive return data from Service 25 0 to formulate a Response 262 to the Application Object 210. In one solution, a number of such Providers 240 may work simultaneously on the same transaction 220. In another solution, the Providers 240 may go towards the same goal through different channels. For example, multiple Providers 240 may perform multiple Services 250 to obtain the fastest response where response times vary (eg, one Service 250 may be faster than another Service 250 for any given request depending on server availability and other factors).

A service 250, such as a data carrier service or a Communication Protocol service, may be used to exchange data with an external resource, such as a financial data network, a bank, a cryptographic system, or a data warehouse. Each Service 250 can be configured for the communication protocols and data requirements of a specific external resource. Service 250 can both send and receive data, and the received data can then be delivered to Service Provider 240 that initiated Service 250 , appended to transaction 220 , and/or returned to Application Object 210 in Response 260 .

Responses 261 and 262 may contain a response or resolution to transaction 220 created by Application Object 210. Responses 261 and 262 may contain information requested by Application Object 210 or may contain an explanation as to why the request made by Application Object 210 could not be executed. In one solution, the Response 260 may contain a value to indicate whether or not a transaction has taken place; a message explaining why the transaction was not executed; if necessary, a token, such as a reference to the current transaction, that can be used as part of a subsequent transaction; and a series of additional data (as discussed above with respect to transaction 220). The information returned as Response 260 may be returned in whole or in part to the user who initiated the use of the Application Object 210 and/or may be the basis for the next transaction 220 initiated through the same or another Application Object 210.

Figure 3 illustrates an integrated transaction management system 300 that offers a variety of financial customer and information services through a variety of service endpoints 310 that utilize a variety of financial data, content, and transaction functions performed by various remote service providers 320. As shown in Figure 3, the integrated transaction management system 300 contains a number of user-oriented financial and information services. These financial and information systems may be offered to a variety of service endpoints 310 from a variety of interfaces that support one or more interface standards and communication protocols. Some examples of service endpoints 310 may include a PDA 311, a mobile phone 312, a PC 313, a laptop computer 314, a telephone 315, a fax machine 316, an ATM 317, or a POS system 318. The integrated transaction management system 300 communicates with the service endpoints 310 using either which Communications network such as the Internet, telephone network, wireless network, radio network, and other Communications networks and one or more appropriate applicable data transfer protocols including SMS, WAP, and TCP/IP. Services performed by the integrated transaction management system 300 may utilize information collected and/or exchanged with any one or more different remote service providers 320. Some illustrative remote service providers 320 may include a Bank 321, a Credit Card Company 322, a GSM Operator 323, a Biller 324, Content Provider 325, as well as other providers of financial and similar services. The integrated transaction management system 300 can communicate with remote service providers 320 using any secure Communications Network or financial data network.

The integrated transaction management system 300 can further contain a number of functional modules for providing various financial and other information services according to the solution of the invention. Functional modules can contain a combination of software and/or hardware to perform a task or a series of tasks. For example, a data processor, memory, and instruction set (eg, computer program code) may be all that is required for such a functional module to perform the tasks necessary for a given solution of each functional module. However, more often, multiple inputs and outputs, a number of short and long memory systems, a number of layers of computer code (eg, operating system, application software, etc.), a number of communication devices, and multiple processors can be used with each such functional module. In addition, such multiple functional modules may share common hardware and parts of software libraries. In some cases, a functional module may contain one or more such functional modules. As accepted by those skilled in the art, the functional modules described herein may be implemented in a greater number of equivalent combinations of Object codes and hardware. The combinations represented by the functional modules described herein are conceptual and should not be construed as a limiting framework for the multiple hardware and software combinations capable of performing the tasks of the functional modules.

As shown in Figure 3, the integrated transaction management system 300 includes an Interfacing System 330, an Application System 340, an Access System 350, and a Cryptographic System 360. The Interfacing System 330 includes one or more functional modules, each of which provides one or more user interfaces. which can be accessed from a number of service endpoints 310. Application System 340 contains one or more functional modules, each of which offers the ability to process functions from one or more user applications, with the ability to formulate data requests and transaction requests for service providers 320. Access System 350 contains one or more functional modules for routing a series of communications between different separate networks or communication systems that use a series of different communication, data transfer, and encryption protocols. Cryptographic System 360 contains one or more functional modules for encryption and decryption of data according to one or more security encryption standards.

The Interconnect System 330 contains one or more functional modules for the presentation and exchange of information via a series of separate-client endpoints or terminal devices. Interface System 330 may access one or more functional modules that offer a variety of user applications within Application System 340, and may interface between such Application System 340 and users according to a variety of bandwidths, memory capacities, processing capabilities, input and navigation methods, and common of use and the middle of a series of service endpoints 310 that can be shaped according to the user. For example, an SMS-compatible interface may be limited to 160 text characters for sending and receiving information. A WAP device offers more variety and, therefore, the interface used to communicate with such a WAP device can contain graphics and other data, but must be designed for the limited bandwidth and memory of most WAP devices. Web-based devices can have any range of capabilities, depending primarily on the type of terminal device and the bandwidth, memory, and input capabilities of the intended terminal device. Even with certain communication protocols, it may be more acceptable to offer multiple interface options depending on the range characteristics of possible terminal devices and users.

As shown in Figure 3, Interconnect System 330 includes Web Interconnect Module 331, SMS Interconnect Module 332, WAP Interconnect Module 333, ATM Interconnect Module 334, and POS Interconnect Module 335. Other Interconnect Modules may also be supported by alternative solutions, such as interface modules that support other wireless protocols and communication networks, voice interface modules for telephone access, privatized and LAN interface modules for secure limited access to special services (eg, for side transactions and services of service providers and system administrators), and additional interconnect modules to support new and specialized capabilities of future network communication devices.

Web Interface module 331 offers a series of dynamically generated HTML documents for interactive information exchange with the user. These HTML documents may have a specific locator on the WAN, such as a World Wide Web compatible URL. Web Interface module 331 may also include a web site for offering a variety of online banking, money management, investing, billing management, and other financial services. The Web Interface Module 331 can further provide a variety of specialized web interfaces for various applications, terminal devices, and client software specifications, and user needs. Web Interconnect module 331 can be accessed by the user through any Web-enabled device, such as a PC, WebTV, or other Internet device. Opt-in operations for services offered through the Web Interface Module 331 may be provided by one or more Application Systems 340. For example, the Web Interface Module 331 may link one or more applications in the Application System 340 to specific icons or a series of terminal device function keys that are accessible and may use data located in a terminal device or other data store to automate an application transaction.

The SMS Interconnect module 332 of the Interconnect System 330 offers one or more short text messages for interactive information exchange with the user. The SMS Interface module 332 may offer one or more interfaces each with a range of limited functions that use text messages of up to 160 characters to exchange information. The SMS interface module 332 may further provide one or more interfaces each designed for a variety of limited input options compatible with a variety of limited input options, such as a standard telephone keypad with or without additional keys, as offered by some SMS-enabled devices. The SMS Interconnect Module 332 can be accessed by the user via any SMS-enabled device, such as a mobile phone, alphanumeric pager, or other wireless device with a limited display. Opt-out operations for services offered through the SMS Interface Module 332 may be offered through one or more applications in the Application System 340. The WAP Interface Module 333 may be used to offer one or more pages, such as pages written in Wireless Markup Language (WML). , for the interactive exchange of information with the user. The WAP Interface Module 333 may offer one or more interfaces each with a set of display and input requirements limited to those of common WAP-enabled terminal devices and with a set of bandwidth and memory requirements appropriate for WAP-enabled devices. The WAP Interconnect Module 333 can be accessed by the user through any device that supports WAP, such as a mobile phone, pager, two-way radio, smart phone, communicator, and other handheld wireless device. Opt-out operations for services offered through the WAP Interconnect Module 333 may be offered by one or more applications in the Application System 340.

ATM Interface Module 334 provides one or more interface screens for interactively exchanging information with a user via an ATM, such as ATM 317. ATM Interface Module 334 provides interface data to one or more ATMs using separate-client software (eg, a browser) or a non-search based abundant client that provides a range of user services. In one embodiment, the ATM Interconnect Module 334 has a series of HTML pages that can be accessed by a dedicated ATM client using software and communication protocols (eg, TCP/IP) similar to those used to deploy Web pages on the World Wide Web. An ATM 317 communicating with an ATM Interconnect Module 334 can offer a variety of customer services traditionally offered through an ATM, such as a variety of deposit, withdrawal, transfer, and account management inquiry services, as well as access to additional applications, such as account management, transaction management , event messaging, delivery of goods and services, money and investment management, content related to finance and convenience and advertising, among other functions. The ATM 317 may be any ATM, including an international ATM, an isolated ATM (such as a stand-alone ATM in a shopping center or retail establishment), general purpose kiosk and service stations, and other networked exchange computers. The ATM Interface Module 334 can also be used as a gateway to provide limited access to a variety of ATM applications that use hosted interface software to provide a user interface. The waiver operations for services offered through the ATM Interconnect Module 334 may be offered by one or more applications in the Application System 340.

POS Interface Module 335 may include one or more interface screens for interactively exchanging information with a user through a POS system, such as POS 318. POS Interface Module 335 may provide interface data to one or more POS systems using separate-client software (e.g., browser) or non-browser-based bulk client to provide a range of consumer and/or retail services. The POS Interconnect Module 15 may contain a series of HTML pages that can be accessed by a stand-alone POS client using a series of client software and communication protocols (eg, TCP/IP) similar to those used to host Web pages on the World Wide Web. A POS system that communicates with the POS Interconnect Module 335 may offer basic services for the POS system, such as electronic payment transactions, electronic order sets, and customer services for transaction verification and authorization. A POS system that communicates with the POS Interconnect Module 335 may also offer access to a variety of additional applications, such as account balance and transfer inquiries, account management, transaction management, event messaging, delivery of goods and services, money and investment management, content related to finance and retail and advertising, among other functions. A POS system may include a merchant-serviced retail POS system that offers at least a limited user interface (such as a card reader with an alphanumeric display), an unattended POS system (such as a vending machine, automatic checkout system, etc.), a merchandise kiosk, and services and service station, and any other public networked computer used for automatic delivery of goods and services directly to the user. The POS Interface module 335 may also provide a gateway for limited access to applications from POS systems that use hosted interface software to provide a user interface (eg, privatized systems fully integrated with a retail inventory management system). The transaction services offered through the POS Interconnect Module 335 may be provided by one or more applications in the Application System 340.

Application System 340 includes one or more modules that provide functional processing for one or more user applications, including data formulation queries and transaction requests for service providers 320. Application System 340 provides a variety of user applications according to a modular structure that promotes changeability, upgradeability, and universality. for access by a number of interface modules serving a number of service endpoints 310. Application System 340 uses data provided by a number of external service providers 320 as well as internal system and data resources. A single application transaction may simultaneously or subsequently access data on, or initiate data exchange with, more than one service provider 320. Application System 340 may formulate a series of queries and issue a series of data exchange requests based on a series of protocols depending on the location of the system and the information that the user is looking for. Application System 340 may use a combination of Standard Query Language (SQL) and a variety of alternative protocols for exchanging data and transactions, depending on the compatibility of service providers of system 320 with Application System 340. Application System 340 may use a variety of modules that offer a variety of service applications very similar to those described above. modular system 200 with respect to Figure 2. Some examples of Application Modules that may be offered through the Application System 340 include an Account Access module 341, an Account Management module 342, a Transaction Management module 343, an Event Notification module 344, and a Goods and Services Transaction module 345 Each Application Module can contain a number of transaction modules to perform a number of functions that can be contained within the Application Module. The possibilities of additional Application Modules and alternative layouts of Application Modules and component transaction modules are endless.

Account Access Module 341 provides the user with access to account information through any of the interfaces and terminal devices or previously described service endpoints 310. Some example transaction modules include an account status inquiry initiation module that causes a specific service provider 320 to respond to the user with the current status of user's account, a module for requesting a mini-calculation of account history, or a module for transferring a certain amount of funds from one of the user's accounts to another of the user's accounts. In addition, the user may initiate a request to change the user's password, a message related to a report that one of the user's cards has been stolen, or a request to order checks from the financial institution's service provider 320. The user may request to receive messages or alerts at a certain frequency via one or more designated service endpoints 310 related to any of the previously described transaction modules. For example, a user may request to receive an alert once a day informing the user of the balance of any of his accounts. Further description of the messages and alerts is provided below with respect to the Event Message module 344. The Account Access module 341 may also perform a login, user verification, or security transaction, such as prompting the user to enter a user identifier (eg, username , account number, magnetic card information, etc.) and PDST/password. In one solution, one or more specific user identifiers or in another solution, a single login, user identification, or security transaction may be sufficient to perform multiple transactions through one or more Application Modules. The Account Access module 341 may be associated with a variety of account types such as various checking accounts, savings accounts, brokerage accounts, credit card accounts, retail credit accounts, and other accounts. In one solution, the Account Access module 341 may offer a series of simultaneous or sequential accesses to a series of accounts held by the same user through one or more service providers 320 .

Account Management Module 342 provides access to a variety of account management functions through any of the interfaces and terminal devices or service endpoints 310 previously described. Some examples of functional account management transactions may include changing a password, opening an account, closing an account, reporting a lost or stolen bank or credit cards, ordering checks, and initiating other customer service inquiries. As previously described for the Account Access module 341 , the Account Management module 342 may include a login, user verification, or security transaction to ensure that transaction management is accepted only by the true account owner. Also, as previously described for the Account Access module 341, different accounts can be accessed through the Account Management module 342. In one solution, the Account Management module 342 may include a two-way messaging platform for providing a range of customer service inquiry applications. A two-way messaging platform may contain a number of transaction modules such as an area query module (to provide available user service areas), a message sending module (to address a message to one of the user service areas), a message read module, and a message delete module . The two-way messaging platform may also contain a number of secondary service provider transaction modules, such as a message reply module (to respond to a specific user message) and a message broadcast module (to send a message to all or part of the user).

The Transaction Management Module 343 may further offer a variety of automated or on-demand transactions with a variety of service providers 320 that allow electronic payment, presentation, and/or bill payment through any of a variety of interfaces, terminal devices, or service end points 310 described previously. Some examples of transactional of the transaction management modules contained in the Transaction Management module 343 include a payment account balance inquiry module, an account access details module, an account payment module, a module for automatic opening, modification, deletion of a payment account, a module for changing contact information, and a number of other modules that offer other options questionable customer service. The Transaction Management module 343 may also include a module for managing a series of Accounts Payable (ACH) transactions. As previously described for the Account Access module 341, the Transaction Management module 343 contains a login, user verification, or security transaction module. Likewise, as previously described for the Account Access module 341 , a series of accounts may be accessed through the Transaction Management module 343 .

The Event Messaging module 344 provides one or more scheduled or conditional financial information and message management services through any interface and terminal device or previously described service endpoints 310. Some example messaging services may include a scheduled status information service to provide regular alert messages to the user. about the current balance of the user's checking account, conditional changes in account balance messages (eg, a message that alerts the user when a transaction has lowered the account below the minimum required balance), a transaction message service to notify the user of various, such as POS or ATM debit cards over the user's specified account limit, or notification of the execution of an ACH transaction, interest rate change messages that offer the user information about interest rate changes, and a service that allows the user to create, modify or delete a subscription to the user's message service. The Event Messaging module 344 may enable the user to receive messages containing informational content, such as stock prices, sports scores, weather forecasts, event reminders, advertising and marketing information, and other general information, on separate subscriptions or as part of the user's financial services message. Event Messaging module 344 may provide the user with such notifications and content delivery via more than one service endpoint 310. For example, the user may receive text messages via mobile phone 312 offering the user notifications and messages of limited content. The user can then access the ATM 317 to access additional message content. The Event Messaging module 344 may also use a combination of a number of subscription messaging services and personalized conditional filtering to manage the delivery of messages to individual users. Enhanced security may be provided by requiring the user to perform a login, verification, or security transaction, as previously described for the Account Access module 341 , prior to using the ATM 317 .

The Goods and Services Transactions module 345 offers the delivery of goods and/or services through any interface and terminal device or the previously described end service point 310. Examples of such goods and services transactions that can be performed by the Goods and Services Transactions module 345 include the sale of subscriber long-distance services, the sale mobile phone services or Internet access, cash withdrawals in conjunction with the POS system, and person-to-person transactions of goods/services. For example, a voucher, including an access code or verification number, may be delivered to a terminal device, such as an ATM 317. The voucher may be exchanged with a user for services or goods requested by the user. Each type of transaction that may be performed by the Goods and Services Transaction module 345 may include a service request transaction, a voucher verification transaction, and a voucher reimbursement transaction. For example, a user with a mobile phone may notice that his subscription time for mobile phone use is running out. A service request transaction can be taken by a user of the Service Transactions Module 345 using a mobile phone, then the user can send the Service Transactions Module 345 one of the user's debit or credit card numbers to pay for the purchase of additional time, and an access code can be assigned to the user by the Service Transactions Module 345 The access code can then be sent by the user via mobile phone to the telephone company. The company verifies the access code and assigns the value paid to the user's phone bill. The value that has been paid can then be taken from the user's fund in the bank account and transferred to the telephone company through various EFT channels. A similar process can be done for any transaction between any two parties, as long as one party can make a voucher request to the Service Transactions 345 module and the other party can verify and redeem the voucher. In one solution, the verification and reimbursement functions can be combined into a single transaction. In one solution, the function of submitting the voucher to the compensating party can be automated so that neither party actually sees the voucher. In the example of the airtime purchase transaction described above, a request for airtime may cause a voucher to be automatically sent to the telephone company for processing. Different devices can be used to request and receive vouchers versus submitting vouchers for verification and reimbursement. For example, a user can use ATM 317 to request and receive a voucher, but then enter the voucher number the same as the credit card number at the start of a phone call from any phone.

As shown in Figure 3, the Access System 350 contains one or more modules for managing communications between one or more separate networks or communication systems using different protocols for communication, data transfer, and encryption. For example, the Access System 350 may include an EFT Protocol module 351, an Internet Protocol module 352, and a Privatized Connection Protocol module 353. The Access System 350 may further include a Communication Gateway, essentially as previously described with respect to the Communication Gateway 110 in Figure 1.

As further shown in Figure 3, the Cryptographic System 360 contains one or more modules for data encryption and decryption according to one or more encryption security standards. Cryptographic System 360 further includes the cryptographic hardware and software substantially previously described for Cryptographic System 121 in Figure 1 .

Figure 4 shows an example method for securing an event messaging application using an integrated transaction management system, such as the systems described in Figures 1-3. The described event messaging application allows the user to select or subscribe to one or more of the various available regular and/or conditional alerts. The alerts themselves contain some form of notification via one or more service endpoints connected to one or more communication networks that interact with the integrated transaction management system. Alerts may also contain messages or additional information, such as sound, graphics, and data. Alerts may be delivered through a single delivery, may be delivered interactively, or may contain a partial delivery and require the user to access additional alert content through an alternative service endpoint or procedure. Alerts can be used to provide real-time financial data and account and transaction tracking, access to current information (eg, sports scores, weather forecast, etc.), or a simple reminder of events and meetings. The steps described below are only offered so as not to be construed as limiting the range of event messaging applications or other user applications that may be offered through an integrated transaction management system.

In step 401, the user may register for alert services. Registering for alert services may include selection of one or more predefined alert services, such as account balance updates, minimum balance alerts, transaction alerts, sports scores, weather forecast updates, and other services. Subscriptions to alert services define the general content and type of alerts that the user will receive. Additional terms, information filters, and handling instructions may be provided on a user-to-user basis. The registration of the warning service may include the establishment of database rules and registration databases or may use or augment existing database rules and registration databases (or the data it stores). The registration database contains a series of tables for common event messages according to the user's preferences, including a table that associates the user's unique identification number with all of the user's bank accounts, a table that associates the user's unique identification number with all of the user's debit and credit cards, and a table that associates the user's unique an identification number describing one or more service endpoints through which the user wishes to receive messages, including, for example, a PDA, mobile phone, PC, laptop, telephone, fax machine, ATM, or POS system. The registration database further contains a table that associates the user's unique identification number with a password for the user to access the integrated transaction management system, and a table that describes a set of notification rules that are used to determine the set of events for which the user wishes to receive messages, for example, a rule that describes the frequency with which messages will be delivered, a rule that describes any restrictions on service endpoints used to deliver messages (for example, no phone use after 10:00 p.m. and PC email use after that time instead). Policy and registration databases may also be used by transaction management systems to enable other financial transaction applications, in addition to the event messaging application, and to define preferences for use within those services. It is possible for the user to enter the necessary information for the registration database initially through an individual setup procedure before any use of the event messaging application. Once the setup procedure is performed by the user, the user's registration database is located as a unique profile in a data resource that is part of or in communication with an integrated transaction management system. Therefore, the user can use any of the defined service endpoints to perform a number of financial and other information services as previously described. When a remote service provider wishes to offer for use an integrated transaction management system may require access to or copy of each of a number of user registration databases in order to compare each user with their preferences stored in the registration databases.

In step 402, the user may add, modify, or delete one or more alert subscriptions and may modify some or all of the preferences that are located in the policy and registration databases. As is known to a generally knowledgeable person, the user can change the password, notification rules and any of the user's preferences initially placed in the registration database by accessing the system through one or more service endpoints from which it is possible to manage the application. Step 402 may be initiated at any time after initial user registration.

In steps 410 and 420, one or more alert transactions may be initiated via the event messaging application of the integrated transaction management system. Alert transactions can be based on scheduled event service (step 410) or conditional event service (step 420). The Scheduled Events Service contains alerts based on scheduled events, such as an update week, a specific date or time event, or other schedule. Conditional Event Services are those based on the occurrence of one or more events, such as checking whether an account has fallen below a certain level. Some scheduled events may have conditional filters applied to them and some conditional events may require regular monitoring to periodically check if the conditions are met. An alert transaction can contain all the information needed to evaluate alert conditions, filter data, manage messages, and message content. For example, an account balance update alert transaction may contain the account number, account balance, time and date stamp indicating when the information was generated by the bank's account system, and other information. The initialization of an alert transaction for execution by the application system may depend on the preliminary evaluation of the initial triggers for regular or conditional alerts.

An alert transaction based on regular events (step 210) may be triggered depending on the evaluation of a scheduled event (step 211) or a service message count by an external service (step 212). Evaluation of a scheduled event (step 211) may initiate a location-specific alert transaction for a specific user or user account when the scheduled time occurs. For example, if a user has an alert scheduled to receive their current checking account balance at 9:30 a.m. every Monday, then when the clock in the integrated transaction management system reads 9:30 a.m. on Monday, a new alert transaction is initiated for the user. An alert transaction may or may not require the system to initiate a service to retrieve data from an external service provider. In the case of a checking account balance, a service inquiry (step 213) may be sent to the bank's accounting system. Alternatively, the scheduling service may be operated by an external service provider and the transaction management system may receive a service message (step 212 ), such as an XML message, from the external service provider that hosts the required external data. For example, a bank may send a message containing account balances at a scheduled time, or a weather service provider may send a morning forecast at a scheduled time. When a message containing information for a scheduled alert is received, it may be filtered to ensure that the alert was actually scheduled by the transaction management system (step 414) and was not the result of a bank error or other type of service request. In one solution, common scheduled events for multiple users or accounts can be processed together via a combined query to the bank's accounting system. Once an alert transaction is initiated and contains data from which to compose an alert message, the data and one or more system conditions may be evaluated against the database rules in step 430 .

The alert transaction based on the conditional event (step 420) may be based on a message received from the service provider (step 421) or any transaction sent through the Communication Gateway that is part of the transaction management system (step 422). Some alerts that appear as conditional alerts to the user may be initiated through periodic checks of scheduled event conditions as previously described for scheduled event alerts. As previously described for step 412, the message that may be received from the service provider contains the data on which the conditional alerts are based (step 421). In this way, banks and other service providers can locally monitor changes in account balances and other conditions and only forward data with changed conditions when the notification conditions are met. It should be noted that the conditions on the basis of which the bank forwards data to the transaction management system do not have to be the same conditions as the warnings themselves. The transaction management system may evaluate the data contained in some or all of the transactions sent through its Communication Gateway to detect changes that affect the alert conditions (step 422). A filter may be placed on the data transaction to redirect relevant data to the alert transaction if the data is a candidate for alert (step 423). For example, a filter can be applied to compare the account number in a withdrawal transaction sent through the gateway to the list of account numbers enabled for minimum account balance alerts. Data from any withdrawal transaction with matching account numbers can then be used to initiate an alert transaction. Messages received from the bank containing transactional information or data specifically offered to initiate an alert may also be filtered to establish the status of the alert.

Once an alert transaction is initiated that contains transaction data relevant to the alert conditions, each alert candidate is evaluated based on database rules for the specific user and/or user account to which the alert applies (step 230). The rule database can act as an additional filtering layer to determine whether individually defined alert conditions are met. For example, a withdrawal transaction can provide a basis for initiating alert transactions within the system. However, individual user database rules may specify that only withdrawals over $100 may be grounds for an alert and may further specify that withdrawals of $1,500 from XYZ Mortgage Company may not be grounds for an alert (even though they meet other alert criteria). Custom user-by-user filtering offers detailed personalization for individual users. The policy database can also provide instructions for handling the delivery of the desired alert. For example, a user can specify a specific service endpoint and device and address from which to receive different types of alerts. Common handling instructions may allow the user to define different handling instructions, such as delivery device, security protocol, or content format, based on the alert type, content, and delivery time.

In step 240, delivery of the warning message is initiated. The delivery of the warning message can be handled by the transaction management system as a service sent to the Communication Address through the Communication Gateway. For example, the warning message may be delivered via email, SMS page, automated voice service (for delivery by telephone or mobile phone), or other methods. In one solution, the initial delivery of the message may provide notification of the availability of additional alert content and the user may be required to initiate a transaction through one or more service endpoints to receive an accompanying alert message. For example, the user may receive a short message notifying him of the availability of a billing or payment account (eg, a credit card account). The user can then initiate a transaction to view the entire billing account or account via ATM, via the Internet, or via any other system that supports applications and interface servers. The event messaging application may offer secure delivery (step 241 ) that requires authentication of the user's identity prior to delivery of the entire message content. This can be offered through a notification system that then prompts the user to access all content via a transaction with security protocols, or it can be delivered through an interactive transaction that prompts the user to enter a password, PIN, or other information to authenticate the user. The event messaging application may offer to deliver and request a response from the user (step 242). This may allow the user to set transaction authorization rules before the content transaction is completed. For example, an event messaging application may notify a user of an attempted transaction over $100 using the user's credit card (and made through the Communications Gateway). The user can then offer a response, by calling a specific phone number or sending a short message through the two-way messaging system to either accept or decline the transaction attempt. The event messaging system can offer an alternative and delayed delivery of a warning message. The user can define a hierarchy of delivery methods or delivery conditions, which the system can step in response to a failed delivery attempt. Among the delivery conditions may be a hold command that stops the alert message for a specified amount of time before attempting delivery again. In this way, alerts can be delivered on the user's schedule and retries can be made in case the delivery method does not work, such as if the user's mobile phone or pager is turned off.

This invention is described in connection with accepted solutions. These solutions are given as examples only. Those skilled in the art are expected to recognize that modifications may be made to these accepted solutions without departing from the invention defined herein.

Claims (24)

1. An integrated transaction management system characterized by the fact that it consists of: a) Communication gateways for the transmission of transaction data to and from at least one of a number of financial data networks that use one or more / different communication protocols; b) Application system consisting of a series of modular financial services applications, said Application System for transferring transaction data for at least one of the series of modular financial services applications to and from at least one of the series of financial data networks through the mentioned Communication Gateway. c) at least one server interface, said server interface that offers interfaces between said Application system and at least one of a number of service endpoints. 2. Integrated system for managing transactions according to claim 1 characterized by the fact that a series of modular applications of financial services contains: a) account access service; b) account maintenance and management service; c) automated transaction management service; and d) event message service, 3. The integrated transaction management system according to claim 1, characterized in that a series of modular financial service applications contains an account access service, said account access service contains at least one of a series of service transactions including access to account balance, access to account history, and access to balance transfer. 4. Integrated transaction management system according to claim 1, characterized in that a series of modular financial service applications contains an account maintenance and management service, said account maintenance and management service contains at least one of a series of service transactions including opening a new account, closing an existing account, changing a user's password , reporting a lost/stolen card, ordering checks, initiating customer service requests. 5. Integrated transaction management system according to claim 1 characterized by the fact that a series of modular financial service applications contains a transaction management service, said transaction management service contains at least one of a series of service transactions including inquiry account balance, access to account details, payment, automatic management of account payment, changing contact information, initiating customer service requests. 6. An integrated transaction management system according to claim 1, characterized in that a series of modular financial service applications contains an event message service, said event message service contains at least one of a series of service transactions including message service maintenance, common message service, and access to message content. 7. The integrated transaction management system according to claim 6 characterized in that the user selects at least one message service from the set of scheduled message services for account balance updates, conditional account balance updates, conditional transaction updates, final transaction updates, financial information updates, and information updates. 8. An integrated transaction management system according to claim 1, characterized in that it is further composed of a universal registration database that contains a series of tables, including a table that connects the user to one or more user account numbers and service provider identification for the service provider associated with each user account number . 9. An integrated transaction management system according to claim 8 characterized in that the array of tables contains user account numbers for the user's bank accounts, credit card accounts, payment accounts, and brokerage accounts. 10. An integrated transaction management system according to claim 1, characterized in that the set of financial service applications contains a two-way messaging application for exchanging messages between the user and the service provider via at least one of the set of service endpoints. 11. Integrated transaction management system according to claim 1, characterized in that a series of financial service applications contains: a) savings account service; b) checking account service; c) credit card service; d) debt card service; e) brokerage account access and management service; f) automatic transaction management service; g) event message service; and h) goods and services transaction service. 12. Integrated transaction management system according to claim 1 characterized in that at least one of the series of service endpoints contains: a) a series of personal digital assistants; b) a number of mobile phones; c) a number of personal computers; d) a series of portable computers; e) a number of telephones; f) a series of fax machines; g) a series of Automated Exchange Devices; and h) a number of POS systems. 13. Integrated transaction management system according to claim 1, characterized in that it consists of a cryptographic system for ensuring data encryption. 14. Integrated transaction management system according to claim 1 characterized in that the financial data gateway contains a number of communication channels and a number of communication networks and a distributor for directing and routing traffic in financial electronic data towards the destination of the financial data system. 15. An integrated transaction management system according to claim 14 characterized in that the series of communication channels contains a standard EFT line, a B2B connection using Internet transaction protocols, and a dedicated connection line. 16. An integrated transaction management system according to claim 1 characterized in that a series of financial service applications use information collected from or exchanged with one or more remote service providers, one or more remote service providers including a bank, a credit card company, a GSM operator, a biller, and content provider. 17. Integrated transaction management system according to claim 16, characterized in that the series of financial service applications contains a series of functional modules for ensuring the possibility of formulating one or more data queries and one or more transaction requests from one or more of a series of remote service providers. 18. Integrated transaction management system according to claim 1, characterized in that the series of interface servers contains at least one web interface server, at least one SMS interface server, at least one WAP interface server, at least one ATM interface server and at least one POS interface server. 19. Method for securing financial services through a series of service endpoints, characterized by the fact that it consists of steps: a) providing a transaction system including a series of user interface applications that are accessed through a series of service endpoints; b) accepting the user's service request through at least one of a number of service endpoints; c) creation of a transaction object within the transaction system, including the transaction of data corresponding to the user's service request; d) selection of a series of Provider Objects based on transaction data and system conditions for the execution of predefined parts of the user's service request; e) accessing the network of financial data from the transaction system to execute at least one part of the user's service request; f) assembling the results returned from the array of Object providers within the transaction object; and g) returning transaction results based on compiled results from a series of Object providers to at least one of the service endpoints from which the user's service request originates. 20. A method for securing event messages via a transaction system based on financial data contained in at least one of the user's financial accounts, comprising the steps of: a) tracking at least one of the user's set of financial accounts for the event; b) filtering detected events according to at least one of the warning conditions; and c) initializing event messages at predefined service endpoints based on detected account events that meet at least one alert condition. 21. The method according to claim 20, further comprising the step of evaluating a detected financial transaction that meets at least one warning condition in comparison with a predefined rule base to determine the message delivery conditions and the destination. 22. The method according to claim 20, characterized in that the account events contain a periodic assessment of the account balance. 23. The method according to claim 20, characterized in that the account events contain any financial transaction that changes the balance of the user's account. 24. The method according to claim 20, characterized in that the account events include a change in the transaction status of the account, a payment expiration date of the account, and a change in the terms of the account.