Electronic confirmation: setting future standards

Hannes Stiebitzhofer, team4e.com, Dr. Josef Bogensperger, Austrian Power Trading AG, Vienna, Austria

With increasing liberalization of the European energy market, the number of transactions between individual market participants rises. Each transaction between two energy providers necessitates the exchange of various information items, currently by means of communication media such as telephone, fax and e-mail. As the number of transactions rises rapidly, transaction costs increase proportionately. This is especially the case for fax and e-mail communications which are positively correlated with the cost driver labour.

The following illustration provides ananalysis of the present process chain and an evaluation of the improvement potential of electronic handling. Specifically, it is the process of registering business transactions after their conclusion on the phone in the trading system of the company, as well the exchange of transaction confirmations as a result. Confirmations primarily serve the purpose of reconciling data inputs.

In addition, confirmations provide a written receipt of the business transaction.


Figure 1. Current process chain with cost drivers
Click here to enlarge image

null

Process overview

Figure 1 shows each of the activities in step-by-step sequence. Since the duration of each activity can be measured, it is possible by means of activity-based costing to determine the costs of processing a transaction; i.e., the execution of the listed activities. The costs of each activity are determined by one or more cost drivers. The process chain business transaction registration identifies labour time as the main cost driver, aside from apparent printing and communication costs. The most important cost driver attribute is the fact that it rarely leads to economies of scale, i.e., the total costs grow linearly with the number of transactions.

Process redesign

The process redesign is based on the following assumption: The data entered into the business trading system can be exchanged and matched fully electronically without manual interaction with the respective business partner. Manual interaction is only necessary in the case of discrepancies, and basically consists of an oral resolution between business partners concerning the erroneous data input and the resulting adjustment in trading systems of one or both partners.

Based on the above assumption, the ESAI Rules can be applied to the existing process ” see Figure 2.


Figure 2. Applying the ESAI rules to the current process chain
Click here to enlarge image

null

The following two examples describe how the process is modelled by applying the Eliminate Simply Automate Integrate (ESAI) rules:

  • Printing of confirmation: The eliminate-rule is applied to this activity. A fully electronic process design no longer requires a printout, thus rendering this activity obsolete and dispensable for the new electronic process chain.
  • Storage of confirmation: The storage of confirmations is automated (Automate) by saving to the databank. The storage occurs seamlessly (Integrate) and lasting storage as a whole is simplified. Databank archiving is significantly more efficient than a filing system with fax copies. Hence, the is shown with considerably fewer costs in the newly designed process chain.

Figure 3. Time and cost comparision of paper and electronic process
Click here to enlarge image

null

Figure 3 provides a side-by-side comparison of the present process chain and the newly designed process chain. The comparison illustrates the resulting reduction of lead time and process costs. A cost reduction of at least 50 per cent appears by all means realistic upon the implementation of an electronic confirmation matching system. In addition, a fully electronic process reduces the possibilities of errors due to human interaction and errors. This leads to an additional reduction of operational risks. In order to exploit the full streamlining potential, it is necessary to develop an electronic system which takes over the transfer and matching of confirmations.

Solution approaches

There are two fundamentally different architectures, both depicted in Figure 4, which serve the realisation of a system for data exchange between companies in general, and the exchange and matching of confirmations in particular.


Figure 4. Central versus peer-to-peer architecture
Click here to enlarge image

null

Centralised solution: Each market participant sends data to a centralised node. This node either forwards the data to the designated counterpart, or takes over additional functions, such as matching the electronic confirmations of two business partners. In the case of a match, the centralised node sends an appropriate reply to both parties involved in the transaction. To avoid conflicts, it is in the common interest of all market participants to ensure that the centralised node function is carried out by a neutral third party such as a service provider.

Peer-to-peer (P2P) solution: Unlike the centralised solution, each market participant communicates directly with other participants. With respect to electronic confirmation functionality, this means that the confirmation for a transaction is always sent directly to the transaction counterpart.

Comparison of methods

Both solution methods are now analysed under various aspects.

Metadata: With a centralised solution, each market participant requires only the address of the service provider which administrates the address information for all affiliated parties. With a peer-to-peer solution, each organization communicates directly with other organizations. Thus, address information must also be exchanged between all parties. Nevertheless, it is possible to apply restrictions, such that an organization obtains only addresses for those with whom it actually transacts. These addresses shall be, at any rate, smaller than the total number of market participants.

Performance: With a centralised system, the centralised node is always the most vulnerable point ” if bottlenecks arise here, all connected participants will be affected. With a peer-to-peer network the load is always distributed evenly among market participants. A performance bottleneck in a network causes problems for the directly connected node, but it does not affect the exchange connection between other nodes.

Availability: The following malfunction scenarios are examined in view of the topology of both dissimilar approaches.

  • The centralised node is unavailable in a centralised solution: The failure of the centralised node in a centralised solution has the result that none of the market participants are able to exchange information. This equates to the worst case scenario.
  • An end node is unavailable in a centralised solution: The failure of an end node, i.e., the connection of an organization to the service, means that this organization is cut off from the others, while their communication remains uninterrupted.
  • A node of a P2P solution is unavailable: The failure of a node, i.e., the connection of an organization to the others, means that this organization is completely cut off from the others, while their communication remains uninterrupted.

Hence, there are high demands on a centralised service, since the failure of the centralised node would result in a complete standstill. Failure of an end node, on the other hand, impacts the other market participants only if they need to exchange information via the unavailable end node.

In this regard, a P2P solution is always favourable to a centralised solution. Furthermore, a centralised service poses an easy target for DOS (denial of service) or DDOS (distributed denial of service) attacks. P2P networks are hardly vulnerable under this aspect as they are distributed in entirety.

Security and trust

Both approaches are internet technology-based. For this reason, it is necessary to protect data from third party access, regardless of the approach, by means of existing secure data transmission technologies.

With a peer-to-peer solution, organizations exchange data which is already known to both. In this case, it is only necessary to technically ensure that transmitted data in fact originates from the particular organization. For the most part, this is a matter of message exchange design and the application of user authentication technology. With a centralised solution, data is sent to a neutral third party. In this regard, trust must be evaluated not only on the basis of technical competency of the third party, but also on a higher level, since by definition, the service provider gains access to information that, based on conventional business practice, would only be known to both business partners.

Based on the above analysis, it generally can be said that a peer-to-peer solution offers the more advantageous architecture, especially in light of the following points:

  • Performance: In a peer-to-peer network the load is distributed evenly to all participants, so that no major hardware or software investments are needed to avoid bottlenecks.
  • Availability: Based on the distribution of all market participants, an overall superior availability is achieved with less effort.
  • Trust: Data is only sent to parties directly involved in the transaction. All implications like compliance troubles resulting from data transmission to a third party are therefore eliminated.

Outlook

In 2003, the company team4e.com technology and management consulting gmbh developed the prototype for a peer-to-peer system in close cooperation with the APT Power Trading AG. The working papers of the European Federation of Energy Traders (EFET) provide additional groundwork, having developed both the specifications for an XML language to describe confirmations as well as the fundamental procedure for confirmation exchange and matching used for peer-to-peer communications.

A simplified exchange and matching cycle of a confirmation consists of the following steps:

  • Step 1: After entry of the transaction in ETRM, both parties generate a confirmation, which is read by enerbility.
  • Step 2: On the basis of the counter party’s ETSO identification code, enerbility looks up the URL of the receiving entity.
  • Step 3: Both counterparties send each other a confirmation for the transmission.
  • Step 4: The buyer checks if the incoming and outgoing confirmations match.
  • Step 5: If incoming and outgoing confirmations match, the buyer sends an authentication document to the seller. This successfully validates the transaction upon which the confirmations are based.
  • Step 6: Following the successful validation of the transaction, enerbility sends an authentication message to ETRM, so that the status can be updated (if supported by the particular ETRM).

The implementation of software is based on the principle of web services. According to W3C, a Web Service is defined as: “A software system, which is identified by a Uniform Resource Identifier ( URI), whose public interfaces are defined and described in XML. This definition can be detected by other software systems. These systems can interact with a Web Service in a mode described by XML by means of an exchange of XML messages via internet protocols”.

The enerbility software does not meet all criteria. In particular, the employed sevice can not be automatically detected because the address information, common for web services, is not published.

Currently, address information must first be exchanged by email or telephone and then entered by the software user. All other aspects of the definition are employed by the software. From a technical point of view, the system features the following characteristics:

  • Data exchange takes place with the protocol HTTP 1.1, secured with SSL.
  • Java was used as a programming language. A servlet engine according to specification 2.3 is required as basis infrastructure. Thus, the software can be run on many platforms and it is possible to use all application servers currently available as infrastructure.
  • The database link-up connection is abstracted by JDBC. Hence, any database system can be employed.
  • The user interface was adapted to HTML 4.0 and can therefore be operated with any modern browser.

Aside from core functionality, the software offers additional features:

A graphic administration interface allows easy user and metadata administration (address data of parties where confirmations may be sent to).

A graphic user interface allows the user to track the status of all incoming and outgoing confirmations at a glance.

Confirmations can be automatically copied from a trading system via a file-based interface. Likewise, status updates can be sent to trading systems per XML messages.

As of March 2004, the software is being tested intensively in parallel with old process operations by APT Power Trading, ATEL, Statkraft Markets and E.ON Sales & Trading. The next business process to be included in the software is the confirmation exchange process between energy traders and brokers.

No posts to display