NZ727351B2 - Financial transaction system - Google Patents

Abstract

financial transaction system providing a financial switching engine, the financial transaction system comprising: a distributed plurality of different physical data centres implemented at different respective physical locations, connected together via a private network; a plurality of plugins each configured to perform a different respective function of the financial transaction system; and an operating system on which the plugins run, the plugins being configured to communicate messages with one another in order to perform financial transactions; wherein the plugins are distributed amongst all of the data centres and the operating system is configured to abstract the plugins from the distributed data centres, wherein the financial switching engine is configured to examine content of said messages to determine a destination plugin to send the message to, such that the plugins communicate said messages with one another via the operating system without needing to specify particular ones of said data centres as destinations of the messages, while the operating system and financial switching engine handles routing of the messages between the data centres over the private network without the plugins needing visibility of the routing. configured to perform a different respective function of the financial transaction system; and an operating system on which the plugins run, the plugins being configured to communicate messages with one another in order to perform financial transactions; wherein the plugins are distributed amongst all of the data centres and the operating system is configured to abstract the plugins from the distributed data centres, wherein the financial switching engine is configured to examine content of said messages to determine a destination plugin to send the message to, such that the plugins communicate said messages with one another via the operating system without needing to specify particular ones of said data centres as destinations of the messages, while the operating system and financial switching engine handles routing of the messages between the data centres over the private network without the plugins needing visibility of the routing.

Description

Financial Transaction System Technical Field The present disclosure relates to the field of financial switching engines for performing financial transactions.

Background It is known to provide a financial transaction system for performing financial ctions between various elements, e.g. to route a transaction initiated from an automatic teller machine (ATM) or point-of-sale (PoS) terminal to the settlement system of a financial service provider, or to top-up a prepaid account such as a d phone-time account from an ATM or PoS al. The system includes a ial switching engine which receives ction messages from one element of the system, and comprises a set of rules for directing them to another. The switching engine receives a message, examines its content, and applies the rules to the t in order to makes a decision about where to forward the message.

The financial transaction system can also include other functions associated with the performance of financial transactions, e.g. for checking an account balance or generating other reports, g transactions in a database, or monitoring an account to generate alerts. Euronet application WO 02/13129 A1 discloses a system comprising a plurality of interchangeable, standard-interface, modular ial e applications, each ing a different respective financial service, e.g. one for account access, one for account management, one for transaction management and one for event messaging.

In existing ction systems, the system including the switch and other financial functions are implemented together at a central data centre connecting outwards to its various endpoints (e.g. ATMs, PoS systems, and/or financial provider ment s) via one or more data networks. The data centre may be arranged as a central element mediating between a plurality of different financial networks (e.g. one or more ATM networks, PoS network and/or ial provider networks). There may also be provided a back-up data centre in case of failure of the main data centre.

Summary The existing approach may be described as an "active-passive" approach in that at any one time, only one of the data centres is active. In normal operation the main data centre is active while the back-up data centre is dormant; and in case of failure of the main data centre, the back-up data centre is active while the main data centre is not functioning.

The present disclosure on the other hand provides an "active-active" approach where different data centres are active at any one time. Furthermore, the present disclosure extends this idea to a distributed, based approach where multiple different modular plugin applications are distributed amongst a plurality of different data s over a plurality of different physical locations.

According to one aspect disclosed herein, there is ed a ial transaction system providing a financial switching engine, the financial transaction system comprising: a distributed plurality of different physical data centres implemented at different respective physical locations, connected er via a private network; a ity of plugins each configured to m a different respective function of the financial transaction system, wherein the plugins include one or more endpoint interface modules each configured to interface with one or more financial service endpoint terminals, and wherein the plugins are distributed amongst all of the data centres and the plugins are configured to icate es with one another in order to perform financial transactions; and an operating system on which the plugins run, wherein the operating system is distributed amongst some or all of said physical data centres , the operating system implementing a plugin look-up table mapping the plugins to the ity of different al data centres and recording which plugins are available; wherein the ial switching engine is configured to examine t of a received message to determine a destination plugin to send the message to, and the operating system is configured to abstract the plugins from the distributed data centres, such that the plugins communicate said messages with one another via the operating system without needing to specify particular ones of said data centres as destinations of the messages, while the operating system and financial switching engine handles routing of the messages between the data centres over the private network without the plugins needing visibility of the routing.

In embodiments, ably the financial switching engine is one of said plugins.

Where it is said that the plugins are distributed amongst data centres, this means that different ones of the plugins are stored and/or executed on different ones of the data centres, and/or that an instance of each of one or more of the s is physically stored and/or executed on multiple data centres (i.e. a given plugin is physically stored and/or executed on two or more of the data s). In the latter case, this may mean that the burden for storing and/or executing a given plugin is shared n le data centres, and/or that multiple instances of the plugin are stored and/or executed on different data centres.

For example, the financial ing engine may be stored and/or executed on one data centre while another plugin involved in a ction switched by the switching engine (e.g. a credit card transaction sing plugin, a d account plugin, or an ATM or point- of-sale terminal interface plugin) may be stored and/or executed on another data centre.

Alternatively or additionally, multiple instances of any given plugin such as the financial ing engine may be stored and/or executed on a plurality of different data s.

Further, the plugins do not need to know which data centre they are implemented on or which data centres the plugins they are communicating with is implemented on, and do not need to be programmed to have any visibility or understanding of the underlying distributed nature of the system. Rather, the plugin just sends a message to the operating system and the operating system handles the underlying al routing in a manner that is opaque to the plugins. Thus the system effectively acts as a kind of "private cloud", with the operating system providing an abstraction layer such that the system acts as one logical data centre from the perspective of the plugins.

The distributed system of the present disclosure may be used to obtain one or more of the following advantages. Firstly, in case of failure of one data , the rest of the system can continue to operate with zero downtime except for any modules or ces of any modules (if any) implemented exclusively on the failing data centre. Further, s and/or data centres can be upgraded with zero downtime to the rest of the system. Further, it can provide improved opportunities for load balancing, and/or improved scalability.

In embodiments, preferably the plugins include at least one security module ured to apply cryptography and/or one or more other security measures to ones of said transactions.

In embodiments, preferably the ty module ses a Hardware Security Module.

In embodiments, preferably the plugins include one or more endpoint interface modules each configured to interface with one or more financial service endpoint terminals.

In embodiments, preferably the one or more endpoint interface modules comprise a pointof-sale interface module ured to ace with one or more point-of-sale terminals.

In embodiments, preferably the one or more endpoint interface s se an ATM interface module configured to interface with one or more automatic teller machines.

In embodiments, preferably the plugins include a credit and/or debit card transaction processing module configured to process debit and/or credit card transactions by interfacing with a financial provider system.

In embodiments, preferably the plugins include an online transaction processing module.

In embodiments, preferably the plugins include one or more prepay ction plugins configured to process transactions to top-up and/or redeem prepaid account credit for a d good or service by interfacing with the prepaid account.

In embodiments, preferably the one or more prepay ction plugins comprise a prepay phone plugin configured to process transactions to top-up or redeem prepaid phone credit.

In embodiments, preferably the s include a message filtering plugin configured to filter said messages.

In embodiments, ably the plugins include a reporting module configured to report on ones of said transactions and/or to report on an account status.

In embodiments, preferably the plugins include a logging module for logging ones of said transactions in a database.

In embodiments, preferably the operating system comprises a load management algorithm configured to m load balancing n the data centres.

In embodiments, preferably the operating system comprises a cost-of-routing algorithm configured to determine an optimal route for said messages amongst the data centres.

In embodiments, preferably the operating system is buted amongst some or all of said al data centres.

In embodiments, preferably the operating system is configured to support different communication protocols for communicating ones of said messages between plugins.

In embodiments, preferably said plugins include a ol conversion plugin configured to perform said conversion.

In embodiments, preferably the operating system is configured to interpret different programming languages in order to run different ones of the plugins programmed in the ent programming languages.

In embodiments, preferably the system comprises a database for logging ones of said transactions, and/or storing configuration parameters and/or transaction rules of the system.

In embodiments, preferably the system comprises a data abstraction layer configured to support plurality of database types In embodiments, preferably the data abstraction layer is one of said plugins.

In ments, preferably the data centres are located in different buildings, different towns or cities, and/or ent countries.

In embodiments, ably the private network comprises a private k infrastructure.

In embodiments, preferably the private network comprises a private protocol implemented over a public network infrastructure.

According to another aspect sed herein, there is provided a computer program product providing a financial switching engine, the computer program product comprising code embodied on a computer-readable storage medium and configured so as when executed on one or more processors to perform operations of: acting as an operating system to run a plurality of plugins each configured to perform a different tive function of a ial transaction system which ses a distributed plurality of different physical data centres implemented at different respective physical locations, connected together via a e k, and wherein the plugins include one or more endpoint interface modules each configured to interface with one or more financial e endpoint terminals, and wherein the plugins are distributed amongst all of the data centres and the plugins are configured to communicate messages with one another in order to perform financial transactions; and communicating messages between the plugins in order to perform financial transactions; the ial switching engine examining content of a received message to determine a ation plugin to send the message to, and wherein the operating system is distributed amongst some or all of said physical data centres and is configured to abstract the plugins from the distributed data centres, wherein the operating system implements a plugin look-up table mapping the plugins to the ity of different physical data centres and records which s are available, such that the plugins icate said messages with one another via the operating system without needing to specify particular ones of said data centres as destinations of the messages, while the operating system and financial switching engine handle routing of the messages between the data centres over the private network without the plugins needing visibility of the routing.

Brief Description of the Drawings To assist understanding of the following description and to show how embodiments may be put into effect, reference is made by way of example to the anying drawings in which: Figure 1 tically illustrates centralised and distributed approaches to implementing a financial transaction system, Figure 2 schematically illustrates a high-level architecture of a financial transaction system, Figure 3 schematically illustrates a buted entation of a financial transaction system, and Figure 4 schematically illustrates a ction formed from a plurality of plugin ces.

Detailed Description of Embodiments Figure 1 illustrates the concept of an active-active approach ve to the passive-active approach, and the extension of the active-active idea to a fully distributed, cloud based approach.

Figure 1(a) shows an active-passive implementation comprising a main data centre 102 and a back-up data centre 104. When a client request is ed from a service endpoint terminal (e.g. PoS terminal or ATM), the request message is routed to the main data centre 102 to be processed. Assuming the main data centre 102 is operative then all such client request messages are routed only to the main data centre 102. Only in case of e such that the main data centre is not operative, request messages are instead routed to the back-up data centre 104 to be processed. Hence at any one time only one of the data centres 102, 104 is active.

Figure 1(b) illustrates the idea of an active-active implementation comprising two (or more) data centres 106, neither of which need necessarily be considered the "main" data centre.

When a client request is received from a service endpoint terminal (e.g. PoS terminal or ATM), it may be routed to either of the data centres 106 to be processed depending on the request. Thus some client request message are routed to one data centre 106 and other such message are routed to the other data centre 106, with both data centres being active processing different requests at substantially the same time.

Figure 1(c) shows an extension of the active-active approach to a cloud system in accordance with embodiments disclosed herein. The system comprise a plurality of al data centres 106 distributed over a ity of physical locations, e.g. different buildings, different sites, different towns or , or even different countries. The different physical data centres 106 may each be associated with le servers and/or devices. The different physical data centres 106 are connected together via a e k 110. The private network 110 may be implemented by means of a private physical network infrastructure, or by means of a private (secure) k protocol implemented over a public physical network infrastructure such as the Internet, or by a ation of these.

A plurality of e endpoint terminals 108 (e.g. PoS terminals and/or ATMs) are also connected to the private network 110, and are thus operable to icate with any of the distributed data s 106 via the private network. At any given time, any two, more or all of the different distributed data centres 106 may be active and processing transactions in parallel. When a service request message is sent from a service end-point 108 it may be directed to any one or more of the data centres depending on factors such as the nature of the request, the current load on the system and the cost of g the message. In the cloud approach a plurality of physical processing centres can be represented by a logical processing centre. In an embodiment many al processing centres can be represented by a single, large logical processing centre. In other words in some embodiments the physical processing centres 106 are sed in a "cloud" which a customer can connect to using endpoint terminals 108 via the internet/intranet 110, which may be a e network.

Figure 2 shows the architecture of a financial transaction system in accordance with exemplary embodiments disclosed herein. The main function of the system is to provide a financial switching , acting as an intermediary between a plurality of service endpoint terminals 108 (which are user terminals) and one or more financial providers 210 (the systems at the other endpoint of the transaction where the ction is ultimately processed). To this end the system comprises a financial switching engine 202 (the core switch) and a ity of message filters 208 which act as interfaces or device handlers.

The system also comprises a plurality of additional elements which can be involved in the transactions. In Figure 2, these comprise for example at least one security module 204, and a data abstraction layer (DAL) 220 for interfacing with a database 218.

The service endpoint terminals 108 may comprise for example one or more point-of-sale (PoS) terminals 212, and/or one or more automatic teller machines (ATMs). The financial provider systems 210 may se for example the ment systems of one or more credit or debit card ers, an online banking system, and/or the prepaid account system of one or more ers of prepaid goods or services. The financial switching engine 202 is connected to the service endpoint terminals 108 via one or more message filters 208, e.g. being connected to each type of service endpoint terminal 212, 214 via at least one respective message filter, and via any respective infrastructure of the endpoints 108. For example in Figure 2 the financial switching engine 202 may be ted to the ATMs 214 via one or more message filters 208b and an ATM network comprising an EFTS ronic funds transfer server) 216, and may be connected to the PoS als 212 via one or more message filters 208c, 208d and a point-of-sale network (not shown). The financial switching engine 202 is also connected to the one or more provider systems 210 via one or more message filters 208, e.g. being connected to each provider 210 via at least one respective filter 208a.

The financial switching engine 202 is thus disposed between the service end-point terminals 108 and the er systems 210. The financial switching engine 202 is configured to receive es, examine their content and based thereon switch them onwards to the appropriate element of the system according to a set of switching rules.

For example this may comprise receiving a service request message from a service endpoint device 108 via the respective filter(s) 208b, 208c, 208d, then reading at least enough of the message to determine the nature of the request and forwarding via r filter 208a to the appropriate provider 210 for processing, as well as potentially forwarding the message or information about it to the database 218 via the DAL 220 to be logged. As r example (e.g. as a complementary part of the same transaction) the switching performed by the financial switching engine 202 may se receiving a report message from a provider 210 (e.g. in response to the request) via the respective filter 208a, reading enough of the message to determine its nature as a report, and forwarding to the relevant endpoint al 108 via the respective filter(s) 208b, 208c, 208d. Again this may also comprise a step of sending the report or information about it to the database 218 vial DAL 220 for logging.

Filters 208 are components which perform specialized units of work (e.g. TCP/IP communication, device handlers, MasterCard online messages, etc.). In embodiments filters 208 are components which are not included within the core financial ing engine 202. They may se specialized processes such as device handlers (e.g. ATM, POS), network handlers (e.g., MasterCard, Visa, etc.), and other function-specific processes.

Filters 202 and other non-core ents may "pre-decline" a transaction, but may still be required to route into the core 202 for g and subsequent routing. The core switching engine 202 may detect pre-declined messages and drop into a "declined decision tree" and potentially override pre-declined values.

In embodiments there may be different filter types: standalone s, chained filters and embedded filters. The standalone type of filter handles a complete unit of work (e.g.

MasterCard filter, etc.). Chained filters may be linked in sequence where each filter completes its unit of work and passes the results to the next . As for embedded filters, this concept allows a filter to be ed within another filter so the "master" filter ively appears to be a standalone filter. However, the master filter may in fact se an accumulation of other filters. Likewise, a filter embedded within a master filter may also function as a lone filter.

The filter concept can be used to support a centralized and/or generic network filter as well as network-specific filters which handle unique network requirements (e.g., MasterCard, Visa, etc.). For example the filters 208 may comprise filters for online transaction processing, network-specific online filters, filters for network clearing processing, and/or k-specific clearing filters.

For instance for online transaction processing, a generic network filter may handle the interface layer between the core financial switching engine 202 and the network-specific online s, while network-specific online filters handle each k’s unique messaging requirements and provide the interface layer between the generic network filter and the individual networks.

Regarding the network clearing processing, a separate k clearing processes is typically used by a provider network, ing the incoming/outgoing file processing logic and the clearing user interface. In embodiments r, there may be provided central ngs application, in which case the new architecture is arranged to create a generic clearing application which handles incoming/outgoing files and the ng user interface.

This is implemented by identifying the common clearing functions between all networks so the central clearings application may be designed to accommodate those needs in a generic manner. In order to facilitate the network-specific clearing requirements, the networkspecific clearing filter layer will provide a layer between the central clearings application and the ks. These filters will perform network-specific reformatting between network supplied files and files handled by the central clearings application. In embodiments, these filters will accept and send data from and to the central clearings application in a standardized format. The filters will at data according to network and the standard ing format.

In embodiments these filters may comprise filters specific to particular providers, e.g.

MasterCard, Visa, American s. For example Card-specific filter(s) may comprise: filters specific to managing MasterCard ng processes, a MasterCard Messaging filter and/or a MasterCard administration filter. The MasterCard Messaging filter is responsible for MasterCard-specific message handling and reformatting, and in embodiments also routing to the downstream MasterCard communication filter. The messaging filter might also monitor the downstream MasterCard communication filters at a high level to identify/report issues and node connection issues. The MasterCard administration filter handles MasterCard MIP connections, administrative messaging, and/or flexible message matching to identify response thread.

In embodiments the filters 208 may further comprise communications filter(s) for performing operation of: retrieving incoming messages from the communication line, splitting multiple messages into individual messages, handling cases where messages are split across packets, directing raw messages into the appropriate filter(s) and/or core 202, placing response es on the communication line, maintaining a persistent connection, and/or keeping track of message-level "thread thumbprints" which indicate which thread sent the request so the communication filter is able to return responses to the correct thread. The filters 208 may further comprise ISO-8583 message filters such as: c 83 message filter similar to the ITM Super DCM concept, Host-to-Host Interface (s) and/or H2H to EFTS.

The filter(s) 208a thus e an interface with the settlement system(s) of one or more financial provider systems for performing online transaction processing and/or debit or credit card transactions. Further, as mentioned the filters 208b, 208c, 208d may comprise device handler s for interfacing with the PoS terminals 212, ATMs 214 via their associated infrastructure. Further, there may be provided filters 208 for topping-up or redeeming prepaid account credit, by interfacing to a financial institution and a d account system of the provider of the d good(s) or service(s), e.g. an account of prepaid phone minutes. The ial switching engine 202 sits in the middle connected between these service endpoints 108, 212, 214, provider system(s) 210, and prepaid account(s) (not shown) via the respective (s) 208, and is arranged to switch messages between them as appropriate to the message in question.

The system of Figure 2 further comprises one or more operator user als 224 (distinct from service endpoints 108, 212, 214) which are connected to the database 218. These provide a user interface enabling an operator of the system to access records of transactions that have been logged via the DAL 220 and switching engine 202, as well as setting any configurations or rules of the system that the system enables the operator to control. In embodiments they user ace may provide a broad number of user interfaces such as: system configuration, system management, system health monitoring, k clearing, audit and/or research.

As further rated in Figure 2, the system comprises a security sub-system in the form of one or more security modules 204 for handling the cryptography involved in the transactions being performed, as well as any other security measures. This may comprise a hardware security module (HSM) providing tamperproof management of security keys.

Any ctions that involve messages being conveyed between different physical data centres 106, and over any al connections to or from any of the service nt als 108 and provider systems 210, will be encrypted for ty using a security key.

The security module 204 performs the necessary encryption and decryption as required by the switching engine for reading and/or transmitting messages.

As mentioned previously, the functionality of the system is implemented in the form of a plurality of plugins 222. The plugins 222 comprise units of software and are modular in nature, giving the ability to be enhanced with unique and/or custom features ed by clients. Likewise, they support the ability to t existing functionality without changing other elements. In embodiments everything is implemented as a plugin 222, even the core financial switching engine 202 and HSM.

Hence in embodiments the plugins 222 may se: a plugin implementing the core financial switching engine 202, one or more plugins implementing the functionality of the one or more security modules 204 (e.g. comprising the software of the HSMs), one or more service endpoint interface plugins for interfacing with the service endpoint terminals 108 (via any ated infrastructure such as a PoS network or EFTS server), and one or more transaction processing plugins e.g. for interfacing with the provider system(s) 210. The e nt interface plugins may comprise a PoS plugin for interfacing with the PoS terminals 212 via the PoS network, and/or an ATM plugin for interfacing with the ATMs 214 via the ATM network (comprising the EFTS server 216). The transaction processing plugins are configured to s financial transactions by interfacing to the relevant provider system 210. The plugins may also comprise plugins for online transactions and/or prepaid account transactions. Hence the plugins 222 may implement some or all of the functionality of said filters 208.

In embodiments the DAL 220 may also be implemented as one of said plugins 222. The system may comprise one or more other plugins 222 (not shown) such as: a transaction logging plugin for logging ctions in the database 218 via the DAL 220, a reporting plugin for generating s relating to the transactions (e.g. reporting on account activity), a protocol conversion plugin for converting between different communication protocols used throughout the , and/or a transaction cle plugin for ng the lifecycle of a transaction.

The plugins 222 can be chained together to create transactions, as will be discussed in more detail y.

Figure 3 now rates the actual physical implementation of the system, and particularly its distributed nature. The system comprises a plurality of plugins 222 (such as those discussed above) distributed amongst a plurality of physical data centres 106. The physical data centres are implemented at a plurality of different respective physical sites, e.g. different buildings, different towns or even different countries. In embodiments there may be at least three data centres, or at least ten, or multiple tens of data centres, or even over a hundred upwards. As mentioned, the data centres 106 are connected together via a private network 110, which may comprise a private network infrastructure and/or a private ol implemented over a public network such as the Internet (sometimes called a virtual private network).

Where it is said that the plugins 222 are distributed amongst different data centres 106, this may mean one or both of two things: firstly, it may mean that different types of plugin are implemented at different data centres (e.g. the core 202 at one data centre 106 and the ATM interface 208b at another, etc.); and/or secondly, it may mean that different instances of a given plugin may be implemented in el at different data s (e.g. so instances of the core 202 may be implemented at multiple data centres 106, and instances of the ATM ace 208b may be implemented at multiple data s 106, etc.). I.e. each plugin 222 is physically stored and/or executed on one or more of the data centres 106, with ent plugins 222 at least in part being stored and/or ed on different data centres, or even each plugin distributed amongst all the data centres 106.

Note also that multiple instances of a given plugin 222 may also run in parallel on a given data centre 106. Instances herein can refer to different copies of the same (or substantially equivalent) plugin 222 stored at different data centres 106, or different instances of the same copy g at a given data centre (i.e. the same copy operating on different transactions in parallel).

In between the plugins 222 and physical data centres 106 there is provided an operating system 302 which is configured to abstract the plugins 222 from the underlying, physical, distributed nature of the data centres 106. This means the plugins 222 to not have, and nor do they need, any visibility of the distributed ure of the al implementation of the system. If a given plugin 222 is to send a message destined for another plugin 222, it issues the message only to the operating system and does not y the physical address of any data centre 106 (and nor does it have any need to do so). The physical routing of messages n the data centres 106 running the source and destination plugins 222 (or source and destination instance of the plugins) is handled by the operating system 302 without either plugin 222 needing to know about it – instead the plugin just sends the message to another plugin via the OS, without the plugins 222 needing knowledge of the different distributed data s 106. Thus the s 222 handle the business logic while the operating system handles the underlying physical routing over the network 110.

The operating system 302 itself may be ented in a distributed fashion amongst some or all of the data centres. This may comprise implementing a plugin look-up table mapping the plugins or instances of the plugins to data centres and/or recording which plugins are available, with the look-up table being distributed amongst some or all of the data centres. Alternatively the look-up could be implemented centrally. Either way, when it receives a message from a plugin 222, the ing system 302 can thus look up the actual physical destination which the message should be routed to for processing.

The ing system 302 may also be configured to m load balancing to try to lly balance the load of storing and/or executing the different plugins 222 or instances of the plugins 222 amongst the different data centres 106, so that no one data centre 106 bears an undue burden of the memory and/or processing resources being consumed by the system overall. The load balancing mechanism considers parameters such as: internal resources of a data centre 106 like CPU usage and memory, and external resources like TCP connection, database connection, and network latency. A run-time increase or se in the number of plugin instances is possible if required, and this can be performed ly or automatically. The inbuilt igent load balancing can operate even without a manual configuration change, but in embodiments explicit hints can be made by the operator such as: configuration queue threshold, configuring priority, configuring response time-out, configuring throughput time, and/or configuring memory ption threshold. The load balancing may be considered a form of intelligent message routing.

Further, the operating system may be configured to m a best-cost routing to find the best route for the messages of a transaction amongst data centres 106 over the network 110. This intelligent dispatching provides an automatic calculation of the optimal routing cost based on path latency, message queue size, processing speed, priority, plugin availability, and/or plugin response (e.g. a plugin can define its own node as a defect). The above attributes can be manually controlled by a configuration change, or automatically.

Preferably the operating system is configured to be able to interpret different scripting languages such as Java, LUA and/or C++ (used as a scripting language), and is thus configured to support s 222 programmed in such ent languages. Preferably the system is also configured to support different communication protocols for communicating between different ones of the plugins 222 and/or between the core switching engine 202 and plugins 222. For example the communication protocols may comprise SOAP, REST, ASN.1 and/or an H2H protocol. In embodiments, the protocol conversion may be implemented by one or more of the plugins 222.

Further, the system is preferably database ic in that it comprises the data ction layer (DAL) 220, which supports multiple se types, e.g. SQL, MySQL, eSQL, MS-SQL, DB2 and/or Oracle. In embodiments the DAL 220 may or may not be one of said plugins. In embodiments the database may be distributed amongst some or all of the data centres, or may be implemented centrally.

Figure 4 illustrates an example of a plurality of plugins 222 being chained er to form a transaction, in this case a credit or debit card transaction between an ATM 214 and a credit or debit card provider 210. The transaction is formed using: an instance of a transaction lifecycle plugin 410, an instance of the core financial switching engine plugin 202, an instance of a security plugin 204, and instance of a logging plugin 408, ces of two service endpoint plugins in the form of a communication plugin 404 and an EFT H2H filter plugin 222, and instances of two transaction processing plugins in the form of a credit or debit card filter 208a and a communications filter 406. Plugins are loaded dynamically on a per connection basis. In embodiments the instances of the plugins 222 for a given transaction are brought together and d over its lifecycle by the transaction lifecycle plugin 410.

The ATM 214 issues a t message to the switching core 202 via the EFTS 216 and service endpoint plugins 404, 208a. The switching engine 202 examines the message to determine that it is a request for a credit or debit card transaction and thus determines that it is to be directed to the system 210 of the credit or debit card provider for settlement.

Accordingly, the switching engine 202 forwards the message to the credit or debit card settlement system 210 via the provider interface plugins 208a and 406. Once the transaction is thus settled (or declined) by the card provider system 210, it returns a response to the ATM 214 via the switch 202, interfaces 406, 208a, 208b, 4040 and ETFS 216. Each of one or more stages of the transaction may also be logged in the database 218 by the logging plugin 408, via the DAL 220. The security plugin 204 handles the tion of the messages so that any message communicated between physical data centres 106 are duly encrypted, via the hardware 412 of an HSM.

The described system provides a general and universal real-time switch that is not limited to any particular type of transaction, interface or data format. The above example of a credit or debit card transaction is just one example case of a general architecture which can also be used for many other functions such as online transactions, prepaid account transactions, viewing an account, and/or monitoring an account to automatically generate alerts, etc.

The distribution of the modular s or different instances of the plugins amongst le distributed data centres means that multiple physical processing centres melt into one logical processing centre. This can provide a number of advantages. For example, it allows for zero downtime in case of e or even maintenance. A single defect can be automatically be replaced by other plugins in a different location. r, through this cloud design, real-time upgrade and configuration is made possible by implementing the upgrade at one data centre 106 without needing to change or shut down the rest of the system. s 222 can be refreshed or updated during runtime even without losing tion, e.g. to replace with a new version of the , change the versioned name in the plugin table, or send a refresh message to the plugin . Further, the design provides high performance and scalability, allowing the system to be scaled up just by configuration or even automatically, by adding additional plugins, plugin ces and/or data centres without needing to shut down and/or rework the rest of the system.

The system is flexible and easy to , with s being able to be developed and replaced by third parties. It provides le interfaces to access and manipulate data, e.g.

SOAP, REST and/or ASN.1; and allows le script languages, even LUA. Furthermore, the system provides for automatic load balancing , memory management and an intelligent "cost of routing" calculation.

It will be understood that the system is capable of handling information in addition to financial information. Therefore the system may be considered "universal" in that it is capable of handling any type of electronic message.

The central operating system and plugin approach, as discussed above, enables a distribution of functionalities. The operating system can handle, for example, message delivery, threading, plugin handling, a database abstraction layer, memory management, and performance controls. The plugins can, for example, implement ss logic, and also have the ability to be d to other plugins. Furthermore, the system may y be implemented as a cloud based system.

Embodiments are not limited to any particular type of operating system. The operating system can for example be Linux, s etc. Whichever operating system is used, it can in embodiments ct functionalities to the plugins, such as business logic.

It will be appreciated that the above embodiments have been described by way of example only. Other variations may become apparent to the skilled person given the disclosure herein. The scope of the disclosure is not limited by the described ments, but only by the accompanying claims.

Claims (26)

Claims 1.

1. A financial transaction system providing a financial switching engine, the financial transaction system comprising: a distributed plurality of different physical data centres implemented at different respective physical locations, connected together via a private network; a plurality of plugins each configured to perform a different tive function of the financial transaction system, wherein the plugins include one or more endpoint interface modules each configured to interface with one or more ial service endpoint terminals, and wherein the plugins are buted amongst all of the data centres and the plugins are ured to communicate messages with one another in order to perform financial ctions; and an operating system on which the plugins run, wherein the operating system is buted amongst some or all of said physical data centres , the operating system implementing a plugin look-up table mapping the plugins to the plurality of ent physical data centres and recording which plugins are available; wherein the financial switching engine is ured to examine t of a received message to determine a destination plugin to send the message to, and the operating system is configured to abstract the plugins from the distributed data centres, such that the s communicate said es with one another via the operating system without needing to specify particular ones of said data centres as destinations of the messages, while the operating system and financial switching engine handles routing of the messages n the data centres over the private network without the s needing visibility of the routing.

2. The financial transaction system of claim 1, wherein the plugins include at least one security module ured to apply cryptography and/or one or more other security measures to ones of said transactions.

3. The financial transaction system of claim 2, wherein the security module is comprised in a Hardware Security Module.

4. The system of any preceding claim, wherein the one or more endpoint interface modules comprise a point-of-sale interface module configured to interface with one or more point-of-sale terminals.

5. The system of any ing claim, wherein the one or more endpoint interface modules comprise an ATM ace module ured to interface with one or more automatic teller machines.

6. The system of any preceding claim, wherein the plugins e a credit and/or debit card transaction processing module configured to process debit and/or credit card transactions by interfacing with a financial provider system.

7. The system of any preceding claim, wherein the plugins include an online transaction processing .

8. The system of any preceding claim, wherein the plugins include one or more prepay transaction plugins ured to process transactions to top-up and/or redeem d account credit for a prepaid good or service by interfacing with the prepaid account.

9. The system of claim 8, wherein the one or more prepay transaction plugins comprise a prepay phone plugin configured to process transactions to top-up or redeem prepaid phone credit.

10. The system of any preceding claim, wherein the plugins include a message filtering plugin configured to filter said messages.

11. The system of any preceding claim, wherein the plugins include a reporting module configured to report on ones of said transactions and/or to report on an t status.

12. The system of any preceding claim, wherein the plugins e a logging module for logging ones of said transactions in a database.

13. The system of any preceding claim, wherein the operating system comprises a load management algorithm configured to perform load balancing between the data s.

14. The system of any preceding claim, wherein the operating system comprises a costof-routing algorithm ured to determine an optimal route for said messages amongst the data centres.

15. The system of any preceding claim, wherein the operating system is configured to support different communication protocols for communicating ones of said messages between plugins.

16. The system of any preceding claim, wherein said plugins include a protocol conversion plugin ured to perform a conversion.

17. The system of any preceding claim, wherein the operating system is configured to run different ones of the plugins mmed in different programming languages.

18. The system of any preceding claim, comprising a se for logging ones of said transactions, and/or storing configuration ters and/or transaction rules of the system.

19. The system of claim 18, comprising a data ction layer configured to support plurality of database types

20. The system of claim 19, wherein the data abstraction layer is one of said plugins.

21. The system of any preceding claim, n the data centres are located in different buildings, different towns or cities, and/or different countries.

22. The system of any preceding claim, wherein the private network comprises a private k infrastructure.

23. The system of any preceding claim, wherein the private network comprises a private protocol implemented over a public network infrastructure.

24. A er program product providing a financial switching engine, the er program product comprising code embodied on a computer-readable storage medium and configured so as when executed on one or more processors to perform operations of: acting as an operating system to run a plurality of plugins each configured to perform a different respective function of a financial transaction system which comprises a distributed ity of different physical data centres ented at different respective physical locations, connected together via a private network, and wherein the plugins e one or more endpoint interface modules each configured to interface with one or more financial e endpoint terminals, and n the plugins are distributed amongst all of the data centres and the s are configured to communicate messages with one another in order to m financial transactions; and communicating messages between the s in order to perform financial transactions; the financial switching engine examining content of a received message to determine a destination plugin to send the message to, and wherein the ing system is distributed amongst some or all of said physical data centres and is ured to abstract the plugins from the distributed data centres, wherein the operating system implements a plugin look-up table mapping the plugins to the plurality of ent physical data centres and records which plugins are available, such that the plugins communicate said messages with one another via the operating system without needing to specify particular ones of said data centres as destinations of the messages, while the operating system and financial switching engine handle routing of the messages n the data centres over the private network without the plugins needing visibility of the routing.

25. The financial transaction system of claim 1 substantially as herein bed with nce to figures 1 – 4 and/or examples.

26. The computer program product of claim 24 substantially as herein described with reference to figures 1 – 4 and/or examples. W0