<< Bank Internet Payment System Main Page
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
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.
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):
Beneficiary's Bank The bank which domiciles the beneficiary's account. This bank will be responsible for credit-side advising. In a "pull" payment, the beneficiary's bank EPH will handle the payment instruction, including validation of debit authorities.
Clearing The process of collecting together payment instructions for two or a number of banks and batching and/or netting them for settlement. This may be done as a part of the settlement process, or may precede settlement.
EPH The Electronic Payment Handler - a system which will need to be resident in each participating bank to handle the Network Payment Protocol and select payment mechanisms. EPH is described in the course of this document.
Firewall The security barrier provided by each participating bank which protects against unauthorized access to bank systems from outside the bank. The term Firewall is used loosely in this discussion - it will typically consist of a number of components which are outside the scope of this document.
Intermediary Several kinds of intermediary may be involved in a payment. Non-bank intermediaries may provide services for merchants or consumers to collect payment instructions and forward them to banks involved in the payment. An example would be a service company which collects and batches micro-payments.
Bank intermediaries may process payment instructions on behalf of their correspondents and/or provide payment clearing and settlement services for them. Note that for simplicity in this design considerations document, intermediaries are generally not shown or discussed - the model does not preclude them, however.
Network Payment Protocol The definition of message formats, message flows and security options and facilities which make up the FSTC Payment Protocol proposed in this document.
Originator The party which initiates a payment instruction. In a "push" payment this will be the party making the payment (the remitter). In a "pull" payment this will be the party being paid (the beneficiary).
"Pull" Payment A payment in which the request to move funds is initiated by the party which is being paid - that is the beneficiary. This is analogous in ACH terminology to a "debit" payment (i.e. one in which the result is to debit the other party in the transaction) and implies the existence of a properly certified debit authorization.
"Push" Payment A payment in which the request to move funds is initiated by the party which is paying - that is the remitter. This is analogous in ACH terminology to a "credit" payment (i.e. one in which the result is to credit the other party in the transaction).
Remitter The party which is providing the funds in a payment. In accounting terms, this is the debit party.
Remitter's Bank The bank which domiciles the remitter's account. This bank will be responsible for credit risk controls and for debit-side advising. In a "push" payment the remitter's bank EPH will handle the payment instruction.
Settlement The actual movement of funds between banks (typically in the US this involves the transfer of funds between banks' accounts at the Federal Reserve).
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.
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.
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:
In this case, it is possible to provide significantly better advising of the progress and ultimate completion of a payment instruction. In particular the following would be possible:
The two extensions to existing payments services envisages as a part of the Payments Infrastructure project are:
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.
The applicability of a bilateral approach is limited, once the number of participants
grows above a relatively small number. However, at that point it may be cost-effective to
consider development of a multilateral netting scheme. Such development is outside the
scope of this project, however.
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.
Both of these developments are intended to add value to the overall financial, corporate and consumer community in offering easy access to inexpensive mechanisms for making payments.
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.
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.
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:
Most of the infrastructure required to follow this model already exists in the current bank payment mechanisms. The following additional components are needed:
1. A Network Payment Protocol to allow for industry-standard interface between various payment initiation mechanisms on the client side and bank-specific implementations of EPH on the server side. This Network Payment Protocol needs to specify
2. An Electronic Payments Handler (EPH) - a bank-owned system to receive requests for payment, handle security, acknowledgment and confirmation processing, select payment mechanism and route payment to appropriate bank back-end system.
3. Extensions to the ATM or Point of Sale (PoS) network to support low value, same day payments. Provision by ATM switches of a message to move funds from one customer's account to another, perhaps in different banks, will provide an inexpensive way to move low-value (< $500?) funds with immediate value.
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.
In fact, it is usually not necessary for payment to be completed within seconds, or even within the same processing day. However, the system must support a client request for "immediate" or at least "same-day" (in the normally accepted money transfer sense) transfer of value. This is accomplished by providing payments mechanisms for both large value and small value payments which provide the beneficiary of the funds with value during the current working day, and typically within minutes or even seconds of initiation. The mechanisms are the existing money transfer processing environment (including correspondent bank payments, Fedwire, CHIPS and other in-country clearing systems) for large-value payments. For small-value payments, extensions to the ATM network are proposed (see below), Note that the this is selected as a potential mechanism which would work, but other alternatives may also be explored.
In the longer term, once it becomes possible to settle more transactions on the same day at a low cost, the stability of the clearing system will be improved as transactions move to this mechanism. Low-cost, immediate transactions will also enable more electronic commerce, and cement the place of this mechanism in the overall payment system.
There are many aspects to a payment system being considered a trusted environment, which extend beyond mere perception. The originator of the payment instruction must have confidence borne out by experience that:
The beneficiary needs the same level of confidence that:
The remitter needs the same level of confidence that:
Note that confidence in these characteristics results from long-term successful operation of payment mechanisms and takes many years to build up. Use of existing bank-operated payments mechanisms is a major factor in establishing confidence.
Certainty of payment execution is related somewhat to the previous item. In principle, it is assumed by the payment originator that their instructions will be carried out exactly as they intended 100% of the time. However, several factors might interfere with this in reality (most of which would be the responsibility of the processing banks and would result in liability for compensation).
Many measures are used to avoid these possibilities. The level of sophistication, and the completeness of coverage of potential problems, depends upon the potential loss which would result from the circumstance being protected against. For example, large-value same-day payment systems must provide a much higher degree of protection against loss or delay of an individual payment, than would be necessary in the ATM network which has a practical maximum payment size of $500 - 1,000.
In the current proposal, the use of a standard Network Payment Protocol ensures that no ambiguity will exist in the processing of the payment instruction. It also allows for provision of payment integrity, notification of successful completion (allowing a client to monitor payment processing), duplicate detection and loss detection.
EPH will be responsible for controlling the bank side of the transaction flow, and also for safely passing payment instructions on to the appropriate back office system. It is assumed that back office systems already have levels of control appropriate to their function. EPH will also need to have a robustness appropriate to the highest availability requirements, including redundancy, automated fallback and quickly invoked disaster recovery systems.
In addition to the threat of payment systems malfunctions, the system must protect against all kinds of intentional tampering including unauthorized disclosure of information, fraud and vandalism. It must be impossible for any adversary to:
A variety of mechanisms exist to prevent misuse of payment instructions. These are discussed later, but include certification, encryption, digital signature, firewalls and access controls.
The security mechanisms will also need to be such that the originator of a payment instruction has no opportunity for repudiation beyond those provided by existing established payments practice.
The definition of affordable in practice varies according the services required by the payment originator. For example, the value of a $30 payment which can safely wait until the next day before the beneficiary has value is very much lower than the value of a $30 million payment which is the prerequisite to completion of a vital, time-critical contract. Customers will pay based upon the requirements they place upon the payment system. This assertion is borne out by the variety of existing payment pricing mechanisms. As such, the cost to the initiator of a payment transaction should be based upon the processing requirements - timeliness, security, advising, etc.
The requirement placed upon any public network initiated payment system is that costs to the user are no higher (and over time become significantly lower) than costs resulting from other methods of initiation with equivalent performance. In addition, pricing should be sensitive to the payment instruction characteristics and to the method used to complete the payment.
The payment mechanisms provided in support of Internet Commerce and other public network initiated movement of funds must be accessible regardless of the system or transaction being used by the client. For that reason, an open non-proprietary Network Payment Protocol will be defined which specifies clearly and unambiguously what the client's intent is. This Network Payment Protocol can be followed by any client software on any system which has access to a public network.
In order for payments volume to grow indefinitely, the following factors must be true:
Alternatively it must be possible to develop and deploy a new payments mechanism with the required capacity fast enough to cover the volume growth. EPH design is intended to support the integration of additional payment mechanisms without requiring new user (client) software.
8. GATEWAY from/to Internet
Definition of the Network Payment Protocol and the functions of EPH will ensure that a secure, dependable, efficient and cost-effective gateway exists between an Internet client and the payment server functions of the user's bank. Providers of commercial services which require that funds be moved will be able to use the protocol and the infrastructure provided by participating banks' EPH systems and the current payments systems to ensure that financial aspects of transactions can be completed.
This requirement includes the integration of the FSTC Payment Model with other industry initiatives, such as FSTC Electronic Cheque products, and SmartCard-based digital money systems.
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.
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.
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.
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:
Also needing definition will be EPH to EPH messages (to support end-to-end advising, EPH-to-EPH payments, etc.)
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:
A particular area of potential difficulty is the definition of valid identifier types for individuals, corporations and banks.
During the protocol definition, decisions must be reached as to the requirements which should be imposed by the protocol.
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:
Note that definition of firewall or any other access control technology for participating banks and other parties is outside the scope of this project. Note will be made of the requirements and implications for the Bank's secure gateway to the public network world, however.
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.
Potential additions to message types supported:
Potential additions to content of messages:
Note that it may be possible for EPH to provide customer-to-customer services such as the transmission of non-payment details related to a business transaction. This would be done "out-of-band" - that is apart from the regular payment system flow. Use would be made of transaction identifiers or reference numbers to tie payment details with non-payment details.
Potential additions to security mechanisms (some of these will need to be addressed prior to commercial deployment, but are not essential to a prototype):
Potential additions to payment flows and processes:
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.
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 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 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.
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:
Payment characteristics which would drive selection of the payment mechanism would include 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.
This is the main portion of EPH which potentially needs to be developed independently
for each bank. Even then, though, standard formats could be supported (such as standard
ACH formats, SWIFT formats for Money Transfer, and in Phase 2 emulation of a standard ATM
message format) such that the processing system could accept the transactions essentially
without change. Handling of the physical, logical and application interface protocols
might vary by bank, although again this could be greatly reduced if interfaces were made
to emulate standard external mechanisms such as an ATM server or a SWIFT interface. It is
suggested that such facilities should in any case be built into EPH standard design so
that interface development could be kept to a minimum within each bank.
As interfaces were developed over time to standard transaction processing packages, implementation costs would diminish for new installations.
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
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
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:
� separate accounts were set up just for this purpose
� audit and accounting agreement could be reached
Later an accounting feed could be built, which would allow for full use of Due From accounting tools.
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
Note, though, that it may be difficult to make use of Money Transfer system cost effective, even though all automatic
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.
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.
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.
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
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.
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.
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.
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
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.
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.
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.
The major regulatory challenge is that of establishing what parties to the payment bear what liability under varying circumstances. Reg. E, UCC-4A and other related regulations and laws will only partly spell out these issues. The project will need to include legal advice on how the current legal structures will impact payments to be handled by the FSTC model.
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.
[Home] [About FSTC] [General
Meetings] [FSTC Projects]
[Membership Information] [FSTC Members] [What's New]