<< Bank Internet Payment System Main Page

FSTC Projects
The Bank Internet Payment System (BIPS): Leading the Way to Electronic Commerce

Electronic Payments Infrastructure: Design Considerations

Electronic Payments Infrastructure: Design Considerations

Overall Design Goals

The goal of the Electronic Payments project of FSTC is to design and demonstrate feasibility of an infrastructure which will support electronic commerce and other on-line business and personal financial transactions by providing a secure, reliable, comprehensive and widely available infrastructure for making payments via the existing banking system.

Such an infrastructure benefits banks by allowing them a consistent, secure, trusted way offering the full range of banking products to consumer and corporate customer base. It also allows for the offering of innovative new products which take advantage of new developments in telecommunications technology and enhancements to the existing banking payments system.

Specific objectives are as follows:

A number of new payment needs are emerging as a result of advances in internetworking technologies. These provide support for Electronic Commerce, interactive consumer banking, information merchants and many other potential users of the Banking payments system. The payments system today is effective and potentially capable of handling most of these payment needs. It is the intent of this model to capitalize on the strengths of existing systems, while at the same time addressing some of the new challenges which arise from the on-line payments world. These challenges include the following:

1. The originator of a payment instruction will no longer implicitly specify (by means of the instruction method used) how a payment should be made.

2. Secure, reliable and universally usable mechanisms must be provided for initiating, completing and advising a payment instruction across public networks.

3. Cost-effective mechanisms must be provided for same-day movement of low-value payments.

4. Integration of emerging new payments mechanisms with the FSTC payments model is a dynamic, constantly changing requirement. As an example, it is planned that this payment model should be able to support FSTC's Electronic Cheque product, and SmartCard-based "electronic cash" products, as well as a variety of other third-party payment schemes.

Definition of Terms

In the following design considerations, a number of terms are used which can be understand differently depending upon the standpoint of the reader. The document attempts to use them in a consistent fashion in order to avoid ambiguity. The most important terms used are as follows (alphabetically):

FSTC Payments Model

This section describes the overall model for payments processing which is being developed by the FSTC Electronic Commerce Working Group. Some initial schematics are provided, followed by a description of the major components of the model and a discussion of the major processing flows.

Subsequent sections of this document describe in more detail the objectives and components of the model.

Model Overview

The proposed model is illustrated in the following diagram.

The FSTC payments infrastructure is best understood by considering three potential phases of development. These three phases are further developed later in this document. The phases relate to the extent to which the proposed model is deployed within the banking community, in recognition of the fact that deployment will take a considerable period of time.

Phase 1

The first phase shows the role of the Electronic Payments Handler (EPH) when the payment originator's bank is connected to the Internet, but the bank of the other party to the payment is not.

1. The diagram shows that a payment instruction would be received by the originator's bank for processing. The payment instruction could take a number of different forms:

2. the originator would be using any device capable of conforming to the Network Payments Protocol (discussed in detail later in this document). This could be, for example, a PC, other computer, ATM, Point of Sale terminal or screen-phone.

3. The originator's bank would run a series of software components (either on the same hardware or physically separated) which make up the Electronic Payments Handler. EPH is discussed in detail later in this document.

4. EPH would be responsible for passing the instruction in the right form to a backend payment processing system, receiving responses from that system and passing them back as appropriate to the originator. Such responses could include:

1. Use of the ATM network infrastructure to provide a general purpose method to make same-day low-value payments at a low cost.

2. Use of bilateral arrangements between participating banks to move funds safely and inexpensively through correspondent account relationships, using messages exchanged between each bank's EPH.

3. Under certain circumstances, there may be value in routing credit card authorization requests and responses directly between EPH systems. This may be more timely and less expensive than the current switching mechanisms. Note, though, that this would also imply the development of some bilateral settlement mechanism for credit card transactions which may not be cost-effective.

Basic Transaction Flows

A number of different transaction flows can be envisaged in this model. Most of them are, however, variants upon two basic flows: the "push" model and the "pull" model.

"Push" Model

In the "push" model (see next diagram), the originator of the payment transaction is the remitter of the funds. For example, a consumer wishes to purchase goods or information via an on-line service and is instructing their bank to make payment to the merchant. Another example would be a home-banking customer who wishes to transfer funds from their regular checking account to an account held at another bank.

In each case, the funds are to be pushed from the remitter toward to the beneficiary. The instruction will therefore be handled by the remitter's own bank.

"Pull" Model

In the "pull" model (see next diagram), the originator of the payment transaction is the beneficiary of the payment. For example, an information vendor (or their service company) has accumulated micro-payments for a number of customers during the day. The vendor now wishes to collect payment and is instructing their bank to request those payments from the various customers. Another example would be a utility company which has authority from customers to debit their accounts with the amounts due.

In each case, the funds are to be pulled from the remitter toward to the beneficiary. The instruction will therefore be handled by the beneficiary's bank.

Transaction Flow Tables

The following transaction flow table illustrates the processing flow in a "push" payment:

The following transaction flow table illustrates the processing flow in a "Pull" Payment:

Components to be developed

Most of the infrastructure required to follow this model already exists in the current bank payment mechanisms. The following additional components are needed:

Payment System Requirements

In the overall project objectives, a number of requirements are laid out for the quality of the payments service to be provided. Since these requirements are for the entire end-to-end process, rather than for specific components, this section discusses each of them and the design implications for the whole system or its components.








8. GATEWAY from/to Internet

Network Payment Protocol

The above requirements result in a series of functions which must be carried out in the client software. In order to ensure that the client interfaces with the payments mechanisms at each bank in a standard manner, A Network Payment Protocol will be defined and offered to the development community as an open and freely available set of standards which will ensure that any client software can initiate payment instructions which meet the requirements defined in this document.

Purpose of Network Payment Protocol

This section is not intended to be a design for a new payments protocol. Rather it is the basis for a set of requirements which will be used to select an existing payment protocol, and to propose extensions to that protocol through a formal standards process. The use of existing and emerging standards is essential to the successful implementation of the payments infrastructure on an industry-wide basis.

It is intended that the protocol adopted and extended to meet the FSTC payments infrastructure requirements will be an open and relatively easily implemented standard which can be met by any software developer wishing to support electronic commerce and banking on the Internet. As a part of the project proposal, it is planned that two or more reference implementations will be developed to provide the basis for development and validation of software at the client and server sites.

General Considerations

Definition and selection of the Network Payment Protocol will be a significant activity in the project. The specific message types, content, and flows to be covered in the protocol follow. However there are also some general considerations to be resolved very early in the project process:

Formal definition of the protocol will is essential to the success of the project. Selection of a formal definition syntax (such as ASN.1) and determination of the protocol content and structure will be one of the earliest steps undertaken in the process.

Determination of the general messaging scheme to be adopted, and the relationship between the Network Payment Protocol and lower-level protocols, will be another critical first stage. This would include, for example, definition of one or more new MIME content types. It would also include selection of security mechanisms (such as RSA encryption or X.509 v 3 certification) and how they fit into the overall protocol set.

Network Payment Protocol Components

The Network Payment Protocol will include a number of components:

1. A series of message formats which will state the data content, sequence of data, optional elements and enveloping structure for each element of a payment transaction. Not all of these message types will necessarily be defined initially. Ultimately, though, messages to be defined will include:

2. The payment instruction itself is likely to contain a superset of the data elements included to a lesser extent in each of the other message types. Elements in Phases 1 and 2 will include:

3. Message formats will include specifications for transmittal of security mechanisms to protect the integrity and privacy of the payment instruction. Some of these mechanisms will be optional and will be deployed depending upon explicit requests from the client, or implicit requirements resulting from the characteristics of the payment. Mechanisms should include the following:

4. Transaction flows and application level protocols. This would include:

Future Extensions to Network Payment Protocol

The project proposal envisages the building of a prototype payments model in two major phases, which would address the functionality stated above for the Network Payment Protocol. Future extensions may call for additional message types, message content and transaction flows.

Electronic Payments Handler (EPH)

In order to protect banks from the need to make substantial modifications to their back-office systems infrastructure, it is proposed that an Electronic Payments Handler (EPH) be implemented between the Bank's public network firewall and the various existing legacy payment processing systems. The EPH will provide a trusted interface working in conjunction with the firewall which will allow the banks' back office systems to communicate with public network locations, and through which banks can exchange sensitive information.

Function of EPH

EPH would select the most cost-effective payment mechanism which meets the originator's needs. For example:

1. The originator purchases a coat from an highly reputable on-line emporium, with the understanding that it will be shipped next day based on receipt of funds overnight. EPH will be able to batch this instruction with others like it and pay via the Automated Clearing House (ACH) system.

2. A merchant receives a properly certified credit card payment and passes it to his bank as acquirer. EPH would pass the authorization request through the existing credit card mechanisms to the issuing bank, and would receive the authorization response for forwarding to the merchant. This represents an implementation of acquiring bank support for existing credit card payment proposals from the major card companies, rather than a new credit card payment mechanism.

3. A corporate originator, which utilizes Just In Time inventory techniques, has urgent need of parts supplied by a French distributor. Shipment will be made as soon as pre-advice of the Ff. 2.5 million payment is received by the distributor. EPH will choose Money Transfer (probably via SWIFT advice to the remitting bank's French Franc correspondent) as the appropriate way to make this payment on the following grounds:

4. The originator wants to move $250 from his account at one bank to his account at another for use during today's business hours. ACH would not work because of the timing issue. Money Transfer on the other hand would be too expensive to be cost-effective. The proposed extensions to the ATM network provide the timeliness and cost-effectiveness needed but would still work because of the low value and simple advising needs.

5. An information vendor has established debit authority for daily collection of accumulated micropayments from a series of customers. Collection of all payments resulting from purchases of information could be accomplished securely by allowing for a message to be passed to EPH including the purchaser's authorization to debit in secure form. The merchant would then be responsible for accumulating the transactions, sending a single "pull" payment request for each customer to EPH. EPH would format an ACH debit file on behalf of the information vendor, and pass it through the ACH mechanism for debits to be applied to all of the various information customers.

6. A holder of a SmartCard-based "electronic wallet" wishes to replenish her cash balance. She uses the client software provided with the SmartCard to create a digitally signed request to her bank to debit her checking account and return a certified authorization for her software to increase the balance on her card. Note that this is an example of a transaction in which all processing would be internal to the originator's bank - the originator is, in effect, both remitter and beneficiary. Each of the preceding cases has local variants along the same lines.

EPH Overall Design

EPH is described here in terms of four components:

EPH needs to be designed with as little functionality as will meet the needs of the payment model. This will allow for cost-effective development and deployment of systems capable of handling very large payment volumes. Most of the EPH functionality will be generic and can be built into off-the-shelf package software available on appropriate scaleable platforms. Interfaces to back-end systems will be somewhat custom, particularly where banks use in-house developed transaction processing systems. Individual banks may choose to add service extensions (see Future Extensions below) and also functionality for internal use, such as the following:

EPH Frontend

EPH Frontend will be responsible for providing the "first line of defense" for EPH - that is access security for messages from the Internet destined for EPH. This provides opportunities to isolate the rest of EPH from the Internet. For example, though connection into the EPH Server will of necessity use TCP/IP, a more secure mechanism may connect the EPH Frontend with the EPH Server, such as X.25 or SNA LU 6.2, so that no direct addressing of the EPH Server will be possible from the Internet.

EPH Server

The EPH Server handles the main functions of the EPH and also uses the services of the EPH Certification Server and the EPH Payments Server. All messages coming in from the Internet will pass through the EPH Server. The following functions need to be supported:

1. Handling of the message interaction with the client software which is initiating payment instructions. In effect this means providing the server side of the Network Payment Protocol discussed in the previous section of this document. It includes the authorization cycle and optional acknowledgment to the originator that the payment is being processed, including information about the payment method employed. This may also include negotiation of security mechanisms used in the exchange.

2. Basic validation of the payment instruction to ensure as early as possible that execution problems can be notified to the originator prior to completion of his underlying business transaction. Specific edits will need to be defined at a later stage, but could include the following:

3. Selection (and where necessary negotiation with the originator) of the most appropriate payments mechanism based upon explicit user request and implicit requirements derived from transmitted payment characteristics. The payment mechanisms which can be chosen are seen initially to be the following:

4. Formatting of a message or batch transmission record to be passed to the payment system of record, and management of interfaces to the bank's payment systems. This may include the requirement to batch payments for file transmission, or to warehouse payments which have a future value date on them (since some of the traditional payment mechanisms assume payment is to be made immediately). It is assumed that all other payment processing, including accounting, billing and advising (other than public network advising) would be carried out be the bank's existing payment systems.

5. Handling of status requests via the Network Payment Protocol. This handling may be done directly from EPH, or may be via routing of the request to the appropriate transaction processing system, and forwarding of the response from that system to the client via the Network Payment Protocol.

6. Receipt from bank systems of payment advices intended for delivery to public network destinations, and management of the protocol to be used in passing the advice to the intended recipient.

EPH Certification Server

As EPH handles the security requirements of the Network Payment Protocol, there will likely be a requirement to manage a public key certificate infrastructure. Rather than place that functionality into the EPH Server itself, it is envisaged that EPH will have access to a more general purpose certification server. This may be implemented specifically for EPH, or it may be a general bank software component which EPH can use.

Functions to be performed by the EPH Certification Server are (where necessary):

1. Issuance of certificates to the Bank's customers

2. Validation of certificates received by EPH Server, including access to other Certification Authorities as necessary

3. Revocation of certificates and maintenance of Certificate Revocation Lists

EPH Payments Server

In order to capitalize upon both banks in a transaction having an EPH, it is envisaged that an EPH Payments Server would be developed. This would provide payment processing functions at each bank, and would be the only point in EPH at which direct contact with customer accounts and information would be necessary.

In its simplest form, the EPH Payments Server would receive a payment instruction from EPH Server, which is to be paid to a bank with an EPH. It would carry out risk controls, accounting, message formatting, advising, billing and protocol handling for each transaction. Payment would be settled through a correspondent accounting relationship between the two banks. The correspondent (Due To - Due From) relationship would be funded through traditional means (such as Fedwire draws and replenishments).

If volume warranted it, and credit conditions supported it, the use of funds in the correspondent accounts might be made more efficient if some kind of bilateral netting were in place. Ultimately, there might be potential for introducing some multi-lateral netting scheme which used the EPH infrastructure. However, this is outside the scope of the current FSTC project.

Major considerations for development of the EPH Payment Server include the following:

1. Protocol for security:

2. Message formats:

3. Settlement:

� separate accounts were set up just for this purpose

� audit and accounting agreement could be reached

4. DDA Accounting:

� on-line feed to memo post system

� transactions to post debits and credits

� handling of errors and exceptions

� creation of rejects (insufficient funds, etc.)

� batch feed to system of record (if not on-line)

� audit trails, etc.

� presumably NO manual intervention: any errors just return to sender

� would need a change to reject the payment in the case of insufficient funds, instead of using manual risk control functions

� would need to return an acknowledgment for passing off to the other bank's EPH

� if Money Transfer was used, it could also manage the Correspondent bank accounts

5. Operations:

All of this would probably initially only apply to low-value transactions, or transactions for which the originator simply isn't likely to be prepared to pay Money Transfer dollars. However, as the security and integrity of the interface is proven, there is no reason why payments cannot be processed to whatever value each Bank's Compliance and Risk Management procedures would permit.

EPH Technical Requirements

In view of the criticality of the system it must have an exceptionally high level of availability, recoverability, redundancy and contingency processing. Interfaces must be extremely robust and must be able to detect and recover from all forms of message loss, duplication or modification. These are the characteristics which typically are exhibited today by On-line Transaction Processing Systems. OLTP systems often suffer from the disadvantage, however, that they require significant processing resources per transaction. The primary technical challenge for EPH design is that it must support levels of system robustness appropriate to a full-blown money transfer system, while at the same time using system resources efficiently enough to be able to cost-effectively process payment transaction volumes currently handled only by retail payment switches.

Development of a system which can meet the requirements of EPH may well be best left to one or more software vendors with experience of developing such systems, and who may have an appropriate starting point for such a system already in place. Portability of software would be a major benefit in view of the intent to use this system in banks of all sizes.

International Considerations

The focus of the pilot will be on US payments. However, in order for the FSTC payments model to be generally acceptable there are number of cross-border considerations which must be covered in the course of the project:

1. Payment from US dollar accounts to overseas accounts and vice versa is generally supported only by a subset of the payment mechanisms in use.

2. Export controls for security-related components of the model could have impact if cross-border certification needs exist.

3. Foreign exchange conversion, including mechanisms to be used for conversion and the handling of pre-assigned rates where applicable (some payment-related products allow for automated or trader assignment of a rate prior to the payment instruction being sent out. This allows an originator to know the full cost of the transaction in advance.)

4. Overseas deployment of the FSTC payment model, which implies a number of issues: regulatory, clearing/settlement systems, liability, security export controls, etc.

Future Extensions

The project proposal envisages the building of a prototype payments model, which would address the functionality stated above for EPH. In addition, a number of potential future extensions can be envisaged. These fall into the categories of additional payment mechanisms, and additional services.

Additional payment mechanisms which might be developed over a period of time could include the following:

1. Bilateral agreements may be reached between large banks to periodically net and exchange payments. See the discussion of the EPH Payments Server above.

2. Bilateral agreements could be further extended as warranted by volumes into a multilateral clearing mechanism which takes advantage of advances in technology and which is particularly well-suited to on-line transactions.

3. Central bank check clearing mechanisms may be extended to support presentment and settlement of "electronic cheques" - EPH would then interface to the check clearing systems rather than ACH for such transactions.

4. Mechanisms will be developed for replenishing "electronic cash" products such as SmartCards.

Additional services which might be offered in the future include:

1. provision of payment escrow services. For example a customer making payment for a product may want the funds held until satisfactory receipt of the goods or information is completed. Banks could hold the funds in an interest-bearing escrow account pending authorization to release.

2. support for Financial EDI transactions (e.g. X.12 type 820 transaction set) as part of ongoing banking system support for Electronic Commerce

3. support for delivery of Cash Management information services and Account Analysis services (e.g. via the X.12 type 821 and 822 transaction sets)

4. accumulation of micro-payments on behalf of information vendors and other low-cost service providers

5. non-financial message switching on behalf of corporate and other customers. This might take advantage of EPH-to-EPH protocols to provide secure, timely and cost-effective movement of commerce-related messages. This would most likely be an adjunct to payment services, allowing "out of band" transmission of transaction details tied via reference numbers to a payment.

Existing Payment Systems

The final component necessary to support the proposed payment model is the set of payment systems currently provided by the banking community. Three specific payment mechanisms have been referred to earlier in this document. Two of these - Money Transfer (also known as Wire Transfer) and the Automated Clearing House (ACH) system - require no change to meet the requirements raised by the FSTC Payments Model. A third - the ATM or Point of Sale network - does require changes.

Money Transfer

Arguably the most sophisticated, and certainly the most expensive, of the payment mechanisms is Money Transfer. It provides the highest level of security, reliability and availability because it typically is responsible for moving very large amounts of money. Of all payment mechanisms used in the US, Money Transfer handles only 0.2% of payment instructions, but moves 89% of the funds! The average transaction size is in the order of $4,000,000.

Money transfer provides its own settlement mechanisms, including correspondent bank relationships (using SWIFT or Telex to pass instructions), the central reserve bank (such as Fedwire) and net settlement mechanisms (such as CHIPS).

Money Transfer is the preferred method for moving large payments, or moving payments which are particularly time-critical. It also provides a variety of mechanisms for advising parties to the transaction, can handle dual-currency payments, and can execute payments through a chain of foreign correspondents when necessary.

Automated Clearing House (ACH)

The ACH systems, which are handled by the Federal Reserve and a number of other national and regional banking industry service providers in the US, provide a very inexpensive method for clearing and settlement of bulk payments. They are essentially file-oriented, and are currently generally restricted to domestic payments for which value is provided on a next-day basis.

Two major types of ACH file can be created:

1. A "credit" file, in which the originator's bank (Originating Depository Financial Institution or ODFI) will batch together a number of payments to made out of the remitter's account, will debit his account one time (with risk checking against a pre-approved daily transaction limit) and will then pass on the instructions to the various beneficiaries through the ACH system. An example of a credit ACH application is a company payroll.

2. A "debit" file, in which the ODFI will receive an instruction from its customer to obtain payment from a number of payment remitters for credit to the ODFI's customer's account. The ODFI would batch the payment requests and pass them through the ACH system for presentment to the various remitting banks. An example would be a utility company which submits a file of payments to be received under previously obtained direct debit agreements. The beneficiary (the ODFI's customer) would be credited in advance of receipt of the funds as a fee-based credit service, thus providing for improved cash flow and simplicity of billing. Subsequent refusals to pay would result in debits to the originating customer's account.

ATM Networks

The transaction flow represented in this model is conceptually rather different from the ATM and PoS transactions normally carried over the ATM networks. The difference is perhaps best characterized by noting that foreign ATM and Point of Sale transactions are in effect "pull" transactions (that is initiated from the beneficiary bank's side and "pulling" the funds from the debit side to the credit). Many transactions which are viewed as likely to use the FSTC Electronic Payments model, on the other hand, are essentially "push" transactions. That is, the transaction request is initiated from the remitter's bank, which will pre-authorize the transaction prior to sending through the ATM network.

Despite the difference in transaction flow, it is believed that the needs of this payment model can be met with changes to existing ATM network and Bank-owned switch software without significant architectural impact. The next major section of this project proposal document discusses the changes which would be necessary to support the requirements of the FSTC Payments Model.

Note that further research into the ATM network infrastructure may reveal possibilities for later extensions of this payment option. If security and settlement risk management capabilities can be increased sufficiently, this mechanism may become a viable payment medium for much larger payments in some circumstances.

Assumptions and Limitations

A number of assumptions have been made about the requirements for this electronic payments processing model.

1. No regulatory implications have been considered, other than reference to money laundering data requirements (from the so-called "Travel Regulations"). It is assumed that existing payment mechanisms will support all other regulatory requirements such those imposed by the Office of Foreign Assets Control (OFAC). However, it may be that certain regulations will be introduced which are applicable regardless of payment type (for example OFAC could be extended to cover all electronically initiated payments) in which case support for such regulations may need to be added to EPH.

2. It is assumed that the beneficiary of a "push" transaction is a customer of a bank which can be reached by one of the payment mechanisms supported here. There is no support included for a Pay Upon Proper Id (PUPID) type of payment, or for the Western Union or MoneyGram models in which cash can be collected by the beneficiary. This is because of the initial assumption that the recipient of an advice of payment receipt is an account holder of the receiving bank. Additions to the model to support this case may be added later, however.

3. No consideration has been given to changes in settlement mechanisms which might be necessary as a result of shifting volumes away from paper and toward electronic payment mechanisms. This could particularly be significant in the ATM network if substantial volume were moved onto it thus potentially increasing settlement risk unacceptably. On the other hand, if new settlement mechanisms were developed to address that risk, the ability to handle larger value payments with the low cost of the ATM network could be introduced.

4. It is assumed that the FSTC payment model does not need to incorporate the transmission of extensive non-payment information along with the payment. This may be addressed by the later development of standards to support "out of band" non-financial data transmission (from EPH to EPH, or from EPH to ultimate recipient) along with reference number standards which support tying financial and non-financial data together.

This document is proprietary and confidential to the Financial Services Technology Consortium (FSTC). For further information about the document, or about the FSTC Electronic Commerce payments infrastructure project, contact the document author, Graham Seel at  gseel@ix.netcom.com.

[Home] [About FSTC] [General Meetings] [FSTC Projects]
[Membership Information] [FSTC Members] [What's New]