STP (straight-through processing, i.e. prompt processing or automated processing) means that responses to different transactions and queries launched from a specific system are sent immediately and automatically, without any human intervention. The first thing to be exactly defined in STP systems is the participants involved in the process, and the identification of those participants that can considered to be endpoints. Transactions and responses thereto are always transmitted between endpoints.
Electra is an electronic communication channel implemented for bank customers, which can be used to access most of the banks’ services. Currently, the system consists of two main components: the central computer operated by the bank and running the server program (Electra server) and the end-user programs installed on the computers of the bank's customers (Electra client program). The Electra client software and the Electra server are in a client-server relationship with each other. The Electra server provides the central functions by connecting to the bank’s internal settlement systems on the one hand and to Electra client programs on the other hand. Its connection with the settlement systems is continuous and mostly real-time, and it functions as a standard server toward client programs. When customers want to use Electra services, they can use the client program to connect to the server, and to their bank’s settlement system through the server. Electra client programs represented the endpoints in the former architecture as these were the only applications having an automatic peer-to-peer connection with the bank’s systems. STP was implemented with the intention to extend the current endpoint to customers’ own systems through the Electra client software. That allows banks to offer a higher level service, also necessary for the fast processing of money market transactions and to fulfil customers’ related requirements.
STP Electra is a solution where banking customers can launch transactions using their own systems, and those transactions are sent to the bank’s settlement systems in an electronic form via the Electra system. Settlement systems then process incoming transactions at the time specified by the processing schedule of the respective bank. The bank can then send (e.g. status) information about processed transactions directly to the clients’ own systems via Electra.
Formerly, the connection between the Electra Client Program and the customers’ own systems was implemented using import and export files and required human intervention. Customers exported their orders from their own system into a file of a pre-defined format. Then they imported that file into the client program, signed it and sent it to the bank. The bank processed the incoming order(s) and included the posted items in the statement of the following day, which the customer downloaded using Electra and exported into a file of a pre-defined format. Finally, he imported the export file into his own system.
The process employed included far too many human factors and was slow to provide feedback compared to the transaction processing rate. Banking systems provide information much sooner than statements available the following day, but that information cannot always be transferred to clients’ systems now, not even if using the export function.
It would an ideal solution if that component of the bank’s Electra system which runs on the customer’s side could be integrated into the customer’s own systems. The customer would always work in his own system and Electra would ‘only’ provide a connection between the customer and the bank.
The Electra client program cannot be simply discarded or replaced with STP Electra since there are customers, mainly small customers, who do not have a proprietary system and so they need the original client program. To offer higher level services, banks must provide a means to integrate customers' own systems into the banks’ systems for customers who want to use advanced services, and they must also continue servicing traditional client programs.
Regarding that we are talking about money and information representing bank secrets, the security of not only Electra but that of the solution projected to the entire system has an especially great importance. Pre-recorded, mostly very simple text data used in file-based communication without any encryption can be accessed very easily, and can even be modified under certain circumstances. STP Electra does not use file-based communication, avoiding thereby the security gaps associated with it. Data transmission is always performed in the form of direct data transfer between specific programs, where data are moved from the memory space allocated to one program to the memory space allocated to another program.
Development of automatic access
The Electra Client Program currently has a graphical user interface, allowing the operator to have continuous control over the functions used. So the client program does not have a program interface yet and, therefore, it is not possible to use any external software to ‘drive’ Electra, i.e. to send data to it or to receive data from it. A new component providing STP services has been developed for the Electra Client Program. This new component will make the bank services provided through Electra accessible even for programs not integrated in the Electra system. Apart from the modifications in the client program, customers’ systems will also need to be developed if they want to use the STP service. The STP Electra software will include an external software component (a routine library), which can be integrated directly into the clients’ systems and will provide a reliable, though in a technical sense low level peer-to-peer connection. Cardinal Kft. will compile the routine library and make it available to customers requiring STP services. This will save these users that part of the programming work which provides the basic functions absolutely necessary for using the service and would require unnecessarily large resources on the customers’ part if they had to compile this as well. The routine library also ensures that the basic functions of the STP interface will be implemented in the same way at different customers, and the maintenance and operation of the common component are expected to be less demanding for both the customer and the bank.
Users can use the Electra Client Program only when they have been identified. A user in the Electra system is always a real, natural person. Users identify themselves by entering their user name and the related secret password. Following identification, the client program performs every operation in the name of the identified person.
In the STP Electra program users are not necessarily natural persons. If the customer can solve the transparency issue, it must be ensured that STP Electra could receive information from the customer’s system as to who wants to perform what kind of operation, and act in the name (using the rights and privileges) of that person.
If the customer solves the issue of user identification in his own scope of authority (e.g. through regulations), and the bank has recognised the customer's system as a closed and audited unit, the STP Electra program can also be set to not identify the user as a natural person. We must continue using an identified 'end-user' in the Electra system; what can happen is that a component of the customer’s system (i.e. a program) will log in into STP Electra using a technical ID. In that case STP Electra will perform operations in the name of the program that the technical ID belongs to. As a consequence of that, the bank will identify not the natural persons working at the customer but only the customer (legal entity).
The regulatory and legal issues concerning system use will be regulated by the STP agreement made between the bank and its customer.
STP Electra architecture - the Client Program component
The Electra Client Program component, which provides STP functionality, is an add-on to the software. STP Electra is another client program with a graphical user interface, which can be used in the same way as if it were a traditional Electra Client Program. The difference between the two is that STP Electra also has a program interface, i.e. any external program can connect to it.
Building such a connection must always be initiated by the external program (e.g. the customer’s system) as STP Electra will not establish a connection with any external program by itself.
Communication between STP Electra and the customer’s system will be SOAP based on TCP/IP, which means that customers must be able to communicate using the TCP/IP protocol to use STP functions. The Electra Client Program will listen to the TCP/IP port selected by the customer on the workstation where the user wants to use STP functionality. STP Electra will serve only requests received through this protocol and complying with the pre-defined protocol. If the workstation running STP Electra is ‘far’ from the (customer’s) system launching the STP request in terms of network nodes, it will be the customer’s responsibility to ensure that TCP/IP-based communication could use the given port on the different network security devices (cf. router configuration).
SOAP messages are in XML format but the system will also allow customers to send and receive data in a format exactly matching the structure of the fixed-format import/export files in use. Current fixed-format data will go through special coding (base64) so that they could be embedded in XML.
Identification of the external program (or the person using that program) is part of the handshaking process. STP Electra will expect a user ID (userid) and a password from the party requesting connection. The ID is the same as the user ID used in the Electra system, which consists of a group code and a short name. Further requests can be sent to STP Electra upon the successful completion of the identification process. STP Electra handles passwords and mistakes exactly the same way as the standard Electra system does. User access rights must be checked for STP access exactly the same way as if the very same operation were launched by a natural person via the graphical user interface. If there is no end-user identification, i.e. the bank identifies only the client (legal entity), then it is practical to give full rights to (technical) users connecting via STP.
The established STP connection is session-based, just like in the case of the client-server relation. No timeout is specified for the connection, which means that STP Electra will not disconnect even if there is not any message exchange for a long time. When the user has finished using the STP connection, he must log out from the Electra server, terminating the connection the very same way as when he uses a standard client program. If the connection is broken at the TCP/IP level for some reason (e.g. the network goes down, one of the programs exits), the open session is automatically closed and a new connection and identification is needed to execute new requests.
STP Electra will perfectly integrate with the current Electra programs used in networks. No new client program needs to be implemented at customers only because they want to use STP functions: it is sufficient for them to run a program instance with STP functionality on one of their workstations. If running in a network environment, the standard Electra solution and STP Electra can use a common database. So when a user needs data which were stored by the client program because, for example, they had been retrieved beforehand, he can immediately access them via the STP interface and does not need to download them again. This approach lowers the load of banking systems.
STP Electra architecture - the component integrated in customers' systems
STP Electra has a routine library containing the basic functions necessary for using the STP service. This library can be integrated in the customers’ systems. This routine library, as well as the STP component of the Electra client, is developed by Cardinal Kft. The basic functions offered by the routine library:
- TCP/IP-level communication between the routine library and STP Electra
- identification and encryption protocol over TCP/IP
- SOAP protocol over the encryption level
- general command (issue STP requests, wait for responses) over the SOAP layer.
The routine library will provide only the highest level layer necessary for the customer's developers to issue general commands. It hides lower level layers as the customer’s developers do not have to deal with those.
The documentation of the routine library will be provided to both the bank and its customers. This documentation comprises of a number of parts, contains a description of the basic functions as well as the definition of STP requests that can be made using STP Electra. Basically, this documentation can be divided into three parts:
- description of the basic functions (use of the routine library and its functions, interfacing and integration instructions etc.)
- STP technical requests and the responses thereto (e.g. connecting, identification, opening a new session, logging out, request and response structures, fill-in and interpretation guides for the fields etc.)
- STP business requests and the responses thereto (e.g. transferring HUF payment orders, receiving account statements, request and response structures, fill-in and interpretation guides for the fields etc.)
Implementation of higher, business logic layers based on the basic functions of the routine library is the customer’s task, which means that compiling and implementing complex business processes (e.g. making HUF payments, connecting, identification; transferring, authenticating and sending in HUF payments; querying the order status, registering and maintaining status information in the customer’s systems) based on the requests included in the documentation is not a task that either the routine library, STP Electra, the bank or Cardinal Kft. should perform. The first and last parts in the example are related to the customer's system, which means that these processes extend beyond the functionalities of STP Electra in most cases. The endpoint is the customer’s system or may go even further than that: to the customer’s partner or principal.
The technical solutions used to implement the routine library assume the least with regard to the circumstances under which it will be used. It requires only such basic standards that are almost automatically present in every development and user environment:
- The routine library will provide a standard dll interface in Microsoft Windows development environments, and we will attach a header file to it written in C.
- The routine library will be a compiled lib file in UNIX environments, complete with a header file written in C.
If the customer has any other custom system, or none of the above solutions work on his system, Cardinal Kft. will offer consultancy to the developers of such systems.
The routine library does not use any technology that would require further investment, expenses, professional skills or dedicated operation on the customers’ part (e.g. a dedicated database manager, a special development environment developed by profit-oriented companies, other, non-standard routine libraries etc.).
The utilisation of the routine library will be regulated by the agreement made between Cardinal Kft. and the bank on the one hand, and the agreement between by the bank and its customer on the other hand. The routine library can only be used to implement STP Electra.