[Federal Register Volume 60, Number 1 (Tuesday, January 3, 1995)]
[Notices]
[Pages 111-123]
From the Federal Register Online via the Government Publishing Office [www.gpo.gov]
[FR Doc No: 94-31980]



-----------------------------------------------------------------------

FEDERAL RESERVE SYSTEM
[Docket No. R-0817]


Federal Reserve Bank Services

AGENCY: Board of Governors of the Federal Reserve System.

ACTION: Notice of service enhancement.

-----------------------------------------------------------------------

SUMMARY: The Board has approved a proposal to expand the Fedwire funds 
transfer format and adopt a more comprehensive set of data elements. 
The new format will be implemented fully by year-end 1997. An expanded 
Fedwire funds transfer format will improve efficiency in the payments 
mechanism by reducing the need for manual intervention when processing 
and posting transfers. Further, the new format will eliminate the need 
to truncate payment-related information when forwarding payment orders 
through Fedwire that were received via other large-value transfer 
systems, such as the Clearing House Interbank Payments System (CHIPS) 
and the Society for Worldwide Interbank Financial Telecommunication 
(S.W.I.F.T.) system. The increased size and more comprehensive set of 
data elements associated with the new format will permit the inclusion 
of the name and address of the originator and beneficiary of a 
transfer, which is required under regulations adopted by Treasury.

DATES: Institutions can implement the capability to receive Fedwire 
transfers in the new format beginning July 1, 1996. Institutions can 
implement the capability to send Fedwire transfers in the new format 
beginning June 23, 1997, at which time all institutions must have the 
capability to receive new-format messages. The conversion to the new 
Fedwire format must be completed by December 29, 1997.

FOR FURTHER INFORMATION CONTACT:Louise L. Roseman, Associate Director 
(202/452-2789), Gayle Brett, Manager (202/452-2934), or Sandra Scales, 
Financial Services Analyst (202/452-2728), Division of Reserve Bank 
Operations and Payment Systems. For the hearing impaired only: 
Telecommunications Device for the [[Page 112]] Deaf, Dorothea Thompson 
(202/452-3544).

SUPPLEMENTARY INFORMATION: The majority of large-dollar electronic 
funds transfers between financial institutions in the United States 
flow over the Federal Reserve Banks' Fedwire funds transfer system and 
the Clearing House Interbank Payments System (CHIPS), which is operated 
by the New York Clearing House. In 1993, the daily average volume of 
Fedwire payments was 277,000 with a value of $824 billion and the daily 
average volume of CHIPS payments was 168,000 with a value of $1,055 
billion. A significant number of these transfers, particularly CHIPS 
transfers, are based on payment instructions received over a message 
switching system operated by the Society for Worldwide Interbank 
Financial Telecommunication (S.W.I.F.T.).
    From time to time, the format used to transmit payment orders on 
Fedwire has been modified to address the industry's need for standards 
that facilitate end-to-end computer processing.<SUP>1 In November 1992, 
the American Bankers Association (ABA) Funds Transfer Task Force, under 
the auspices of the ABA Wholesale Operations Committee, recommended 
that the Federal Reserve Banks adopt a more comprehensive set of data 
elements for wholesale electronic funds transfers, and proposed a new 
Fedwire format. Federal Reserve staff conducted a detailed business 
analysis of the format proposed by the ABA and evaluated requests from 
the Departments of Justice and Treasury to modify the existing format 
to include complete transfer party information in the payment order to 
assist in anti-money laundering efforts.

    \1\The structured Fedwire format, announced in 1986 (51 FR 
43086, November 28, 1986), provided a set of field tags to convey 
third-party transfer information in a specific order within what was 
formerly the free-text section of the message.
---------------------------------------------------------------------------

    In December 1993, the Board issued for public comment a proposal to 
expand the Fedwire funds format and to adopt a more comprehensive set 
of data elements by late 1996 (58 FR 33366, December 1, 1993). The 
proposed format was substantially similar to the CHIPS-like format 
proposed by the ABA, but with minor modifications to accommodate 
certain Fedwire business and technical specifications. The Board 
requested comment on its anticipated effects on and benefits to 
depository institutions.

Summary of Comments

    Comments were received from sixty-seven organizations, including 
commercial banks, clearing houses, credit unions, vendors, and trade 
associations. Most depository institution commenters use a computer-
interface connection to the Federal Reserve for Fedwire transfers. Most 
of the commenters that use a computer-interface connection also use 
vendor-supplied funds transfer software.
    The number of commenters by type of organization is identified in 
the following table:

------------------------------------------------------------------------
                         Commenter type                           Count 
------------------------------------------------------------------------
Clearing House.................................................        2
Commercial Bank/Bank Holding Company\2\........................       46
Corporate Credit Union.........................................        2
Corporation....................................................        1
Credit Union...................................................        2
Federal Home Loan Bank.........................................        1
Federal Reserve Bank...........................................        4
Savings Bank...................................................        1
Trade Association..............................................        4
Vendor.........................................................        4
                                                                --------
      Total....................................................      67 
------------------------------------------------------------------------
\2\Six separate but identical responses received from affiliated        
  institutions were counted as one response to provide a consistent     
  treatment with other single responses received from groups of         
  affiliated institutions.                                              

    The majority of commenters generally were supportive of the 
proposal to expand the Fedwire funds transfer format. The forty-eight 
commenters supporting the proposal included all the trade associations, 
the majority of the largest depository institutions, and the one 
corporation that commented. Many of these commenters noted the 
opportunities afforded by the new format to automate more fully 
institutions' backroom processing and to improve compatibility with the 
CHIPS payment system. These commenters also expressed an awareness that 
this conversion would be very costly to the industry because of the 
required changes in backroom and customer delivery systems.
    Twelve commenters, including three vendors, did not state whether 
they supported the proposal. Many of these commenters noted that the 
format was forward-looking and an important enhancement to the Fedwire 
service, but also the most difficult and costly change ever made to 
Fedwire.
    Six commenters strongly opposed the proposal to expand the format. 
These commenters indicated that conversion of internal and customer 
systems to accommodate the expanded format would be very costly, and 
that those costs would exceed any potential benefits. These commenters 
also noted that the regulatory pressure to carry more complete transfer 
party information was a main driver in the need to adopt an expanded 
format. These commenters did not agree with law enforcement's perceived 
need for this transfer party information to travel with the transfer as 
such information should be readily available at the depository 
institutions. One commenter suggested that the Federal Reserve Banks 
should find a less complex way to expand the format to meet the 
requirements of the Treasury's proposed regulation that would require 
financial institutions to include certain information in payment orders 
they send (58 FR 46021, August 31, 1993) (the Travel Rule).
    The Board believes there are significant benefits to the industry 
associated with an expansion of the Fedwire funds transfer format. The 
Board also recognizes that the implementation costs to both the Federal 
Reserve Banks and industry will be substantial. In the longer term, 
operational gains achieved by automating more fully both the mapping 
between funds transfer systems and the institutions' backroom 
processing should help offset the implementation costs the industry 
will incur.
    The Board has adopted the expanded Fedwire funds transfer format, 
which will be implemented fully by year-end 1997. A detailed 
description of the expanded format and examples of usage for business 
and law enforcement purposes are included later in this notice. A list 
of field tags and a glossary of terms and field tag definitions are 
attached to this notice.

Proposed Implementation Approaches

    The Board requested comment on the viability of three different 
implementation cutover plans and the anticipated effects on and 
benefits to depository institutions of each approach. The Board has 
considered the advantages and disadvantages that commenters attributed 
to each of the implementation alternatives. In defining an 
implementation strategy, the Board considered the risk of disruption to 
the payments system, operational burden, and business needs.
    The alternatives that were considered included an institution-by-
institution full function, staggered-date conversion, a nationwide 
same-day cutover, and a receive-first phased conversion. A brief 
description of each alternative, as proposed, is provided below, 
followed by the comment summary.

Institution-by-Institution Staggered-date Conversion

    Under this approach, each institution would select a date over the 
course of [[Page 113]] twelve months on which to convert both its send 
and receive functions to accommodate the new format. The Fedwire 
software would accept messages in either format and map between 
formats. All participants would be required to complete conversion to 
the new format by a designated date, after which time the current 
format would no longer be supported.
    Participants would implement the new format on a staggered 
schedule. As a result, a participant could send a message in a format 
that the receiver cannot process. In this case, the Fedwire application 
would convert the message to a format that the receiver can process. 
For example, if the receiver was able to accept the new format, then 
messages originated in the old format would be mapped into the new 
format. The Fedwire software would convert the field tags and 
identifier codes to the equivalent fields in the new format. If the 
receiver was still processing the old format, then messages received in 
the new format would be reduced to the old format; however, critical 
payment-related information might be truncated. That is, if the sending 
bank included more information in a field than the equivalent field in 
the old format could accept, the extra characters would be omitted from 
the message delivered to the receiver. Truncation could occur because 
the new format allows a sender to include up to three times as much 
payment-related information as the current format. In some cases, data 
truncation could be very extensive.

Nationwide Same-day Cutover

    Under this strategy, all participants would cut over on the same 
day and would be required to both send and receive transfers in the new 
format. There could be a substantial disruption to the payments system 
if one or more large participants were unable to process the new format 
or were to experience some other implementation-related problem that 
denied the participants access to the Fedwire funds transfer service. 
Complete and comprehensive testing on the part of every on-line 
institution, both internally, with other participants, and with the 
Federal Reserve Banks, would be required for a conversion of this 
magnitude to be successful.

Receive-first Phased Conversion

    This alternative entails a two-stage implementation, wherein 
participants would begin receiving the new format before they would 
begin sending the new format. Messages sent in the current format would 
be converted to the new format by the Federal Reserve Banks' Fedwire 
application, then delivered. As originally proposed, each stage would 
last four to six months.
    During phase one, participants would convert from receiving the old 
format to receiving the new format. In this phase, the Fedwire 
application would accept only messages sent in the old format but would 
deliver messages in the format the receiver was capable of processing. 
That is, until a receiver is capable of receiving the new format, all 
messages would be delivered to the receiver in the old format. Once the 
receiver is able to receive the new format, the Fedwire application 
would convert and deliver messages to that receiver in the new format. 
The Fedwire funds software would convert the message by mapping the 
information in the old format to the equivalent fields in the new 
format. As the field lengths in the new format are equal to or larger 
than the equivalent field in the old format, all transfer information 
would be carried forward. The ``new format'' message will contain only 
the field tags necessary to carry forward all the information in the 
``old format'' message. The converted message may be somewhat longer 
than the original message because information commingled in the third-
party portion of the old format would be allocated to specific field in 
the new format and every field would include a tag. At the end of phase 
one, all participants would be required to have the ability to receive 
transfers in the new format.
    During phase two, participants would convert from sending transfers 
in the old format to sending the new format. In this phase, the Fedwire 
software would continue to accept messages sent in the old format, but 
also would accept messages sent in the new format. Until a sender 
begins sending the new format, the Fedwire application would continue 
to accept the sender's messages and convert them to the new format for 
delivery to the receiver. All messages would be delivered to the 
receiver in the new format. At the end of phase two, all participants 
would have the ability both to send and receive the new format. The old 
format would no longer be supported.
    Eight commenters, including a few large regional banks and a trade 
association representing community banks, indicated that the 
institution-by-institution full function conversion would be the most 
beneficial. Commenters favoring this alternative noted that 
participants would implement the new format on a staggered schedule, 
reducing the likelihood of a major payment system disruption because 
few banks would go through the transition on any given day. Commenters 
indicated that conversion costs would be minimized because institutions 
could convert both the send and receive functions at a convenient time. 
Commenters also indicated that fall back to previous software would be 
easier to achieve if a conversion failed. In addition, the staggered-
date approach would reduce the interdependency among depository 
institutions--the failure of any one depository institution's 
conversion would not delay the subsequent conversion of another 
depository institution.
    Eight commenters, predominately money center banks and one trade 
association, strongly opposed an institution-by-institution full 
function conversion, expressing concerns about the potential for data 
truncation and the possibility that the transition period could extend 
well beyond the proposed sunset date. These commenters emphasized that 
adoption of this alternative would reduce the likelihood of a major 
payment system disruption, but indicated that business risk might 
increase substantially due to the potential truncation of important 
data. The data truncation necessary to support the staggered-date 
conversion schedule also would delay a participant's ability to take 
full advantage of the benefits of the new format until all participants 
have converted.
    Twelve commenters, predominantly money center banks, were very 
supportive of a same-day implementation, anticipating that this 
alternative would reduce significantly participants' costs by 
eliminating the need to support two formats simultaneously. This plan 
would allow all participants simultaneously to take advantage of the 
benefits of an expanded format, including the ability to automate more 
fully incoming transfer processing and message mapping between transfer 
systems. Many commenters favoring a same-day implementation noted that 
CHIPS had successfully implemented a new format using a same-day 
implementation plan.
    Commenters favoring a same-day implementation acknowledged that 
there is significant risk associated with this implementation plan. 
These commenters indicated that the risk of payment system disruption 
could be diminished substantially by complete and comprehensive testing 
on the part of every on-line institution, both internally and with the 
Federal Reserve Banks. Some commenters supporting a same-day cutover 
said that the risk that one or more large institutions may not be able 
to complete the conversion [[Page 114]] could be controlled adequately 
through thorough testing.
    Fourteen commenters strongly opposed a same-day cutover 
implementation plan, due to the potential risks to the payments system. 
Under a same-day cutover, there could be a substantial disruption to 
the payments system if one or more large participants were unable to 
process transfers in the new format or experienced some other 
implementation-related problem that denied the participant(s) access to 
the Fedwire funds transfer service. One commenter suggested that the 
risk of a payment system disruption could be eliminated if this 
alternative were modified to incorporate elements of the other two 
alternatives, that is, the Federal Reserve Banks should accept both 
formats, map between formats, and deliver the old format to any 
participant that failed to convert on the designated date.
    Thirty-eight commenters, predominately large regional banks and 
most vendors and trade associations, indicated strong support for the 
two-phase approach. Commenters favoring the receive-first phased 
approach emphasized that this alternative limits the risk that the 
overall payments system would experience a major disruption because 
relatively few banks would go through the conversion on a given day. 
Some commenters favoring a two-phase implementation recognized that 
costs may be somewhat higher because separate testing would be required 
for the send and receive phases; however, commenters also indicated 
that separating the conversion along functional lines helps minimize 
the risk of a complete disruption of service for both the individual 
participant and the payments system.
    One commenter opposed a two-phase implementation, indicating that 
this solution would likely increase automation costs because of the 
need to support two formats for a period of time. This commenter was 
particularly concerned that a participant's incoming and outgoing 
messages would be stored in different formats, thereby increasing 
storage costs, complicating money laundering monitoring, and creating 
confusion in conversations between banks about a particular transfer. 
This commenter also was concerned that it would be difficult for the 
Federal Reserve Banks to manage and coordinate approximately 300 
computer-interface participant conversions in two phases lasting 4-6 
months each.
    The Board believes that the institution-by-institution full 
function conversion is the least desirable approach from a business 
perspective because the process of mapping transfer messages from the 
new format to the old format may result in truncation of critical 
payment-related information. A sender using the new format would need 
to be aware that a receiver may not use the new format. It is unlikely 
that most participants would choose to track whether the intended 
receiver of each transfer was using the new format, so a sender would 
need to limit the size of all messages or risk truncation of critical 
payment data prior to delivery to ``old format'' participants. There 
would be an increased business risk for all receivers that use the old 
format because any messages sent in the new format could exceed field 
length guidelines, perhaps losing critical payment information in the 
truncation process. The receiver that converts late in the process has 
an increased risk of misapplying payments and incurring posting delays 
because most of the transfers it receives would have been originated 
under the new format and information required to fully identify the 
beneficiary or describe the terms of payment may have been truncated 
prior to delivery. The Board believes that the potential for truncation 
of critical payment information represents a significant business risk 
that precludes the adoption of this implementation plan.
    The Board acknowledges that the same-day cutover implementation 
plan has certain advantages for a select subset of institutions. This 
approach also poses the most risk of a serious disruption to the 
Fedwire system and to the financial markets more generally. A same-day 
cutover requires every depository institution that participates on 
Fedwire using an on-line connection to bring new or substantially 
modified software into the production environment for the first time on 
the same date. The Board agrees that complete and comprehensive testing 
is essential to the success of any implementation plan, but also 
recognizes that testing cannot eliminate fully the risk that one or 
more participants may fail to convert successfully on the designated 
cut-over date.
    Due to the magnitude of the software changes and the large 
population of participants, it would not be feasible to fall back to 
the previous software if problems during cutover were encountered. It 
would be impossible to coordinate the timely de-installation and re-
installation of software at more than 8,000 institutions and related 
procedural changes for more than 11,000 institutions. Even if only a 
small number of depository institutions could not convert successfully 
and these institutions were able to fall back to previous software, 
there would still be the potential for data truncation as described in 
the institution-by-institution alternative if the Federal Reserve Banks 
attempted to map messages from the new to the old format. Due to the 
difficulties associated with recovering or otherwise supporting a large 
number of participants in the event of a failed conversion, the Board 
has concluded that a same-day cutover is not feasible on a large-scale 
basis.
    The Board believes the most prudent approach is a two-staged 
implementation wherein participants begin receiving Fedwire transfers 
in the new format before they begin sending new-format transfers. The 
Board believes that the receive-first phased implementation plan 
minimizes the risks to the payment system and eliminates the need for 
truncating payment-related information during the conversion period. 
The Board recognizes that depository institutions will incur some 
incremental operational burdens and cost to support two formats for a 
period of time. The commenters indicated that most computer-interface 
banks are using software that separates transaction processing and 
record storage along the send and receive functional lines; therefore, 
there should not be a substantial increase in cost to use a different 
format for each function, that is, to send in one format and receive in 
a different format. Further, commenters note that the cost increase 
associated with supporting two formats for a period of time would be 
offset somewhat by the improved training and testing opportunities 
associated with receiving the new format in advance of originating it. 
Nonetheless, the Board recognizes that there will be inefficiencies and 
potential for confusion associated with processing and supporting two 
formats for a period of time. In an effort to minimize costs to the 
industry, the Federal Reserve Banks plan to make the send and receive 
portions of the Fedwire software available at the same time in the test 
environment for testing and software certification purposes. This will 
allow the majority of participants to follow a conversion plan that 
minimizes the duplication of testing and implementation tasks.

Implementation Strategy

    The Board has adopted an implementation strategy that entails a 
phased conversion of the receive and send functions. During the first 
phase of the conversion, when depository [[Page 115]] institutions 
implement the capability to receive transfers in the new format, the 
Federal Reserve Banks will maintain information regarding the format 
that each depository institution is capable of receiving. Based on this 
information, the Fedwire software will convert messages to the new 
format for delivery to institutions capable of receiving that format. 
On the first day of the send conversion period, all participants must 
be capable of receiving the new format and the Federal Reserve Banks 
will no longer deliver messages in the old format. In those cases where 
a depository institution fails to convert the receive function by the 
beginning of the send period, the Federal Reserve Bank would continue 
to post transfers to the depository institution's account and deliver 
advices of these transfers in the new format to the depository 
institution using an alternative method, such as magnetic tape.
    The Board recognizes that some depository institutions have a very 
strong desire to convert both the send and receive function on a same-
day basis. The Board desires to balance the business needs of these 
participants against the concern that the failure of one or more large 
participants may disrupt the payment system. Therefore, the Board is 
adopting a modification to the two-staged, receive-first alternative 
that will accommodate full-function conversion of a limited number of 
depository institutions on the first day of the send period, providing 
that these institutions meet stringent guidelines for testing and 
recoverability. The ideal candidate for a same-day conversion will have 
exhibited previous success in completing a major format conversion for 
a funds transfer application on a same-day basis. The Federal Reserve 
Banks will work closely with depository institutions that desire to 
convert on a same-day basis to determine whether the testing and 
recoverability guidelines can be satisfied.
    A depository institution that fails to convert on a same-day basis, 
and is not successful in falling back to software capable of receiving 
messages delivered in the new format, may experience a severe 
disruption of its ability to receive advices for incoming transfers as 
some participants will have begun sending in the new format on this 
date. In understanding the risks associated with choosing a same-day 
cutover, a depository institution should recognize that timeliness of 
delivery of advices by its Federal Reserve Bank may be affected, which 
could affect the institution's ability to post transfers to its 
customers' accounts on a timely basis.
    Depository institutions are required to implement the capability to 
receive transfers in the new format by the first day of the send 
period. In the unlikely event that some depository institutions fail to 
meet this requirement and will require delivery of messages via an 
alternative method, the Board may impose a charge for such deliveries.
    A more complete discussion of the length and timing of the phases 
of the implementation plan is provided in the description of the 
schedule.

Schedule

    Implementing the format will require extensive application 
development work on the part of the Federal Reserve Banks. Also, 
depository institutions using in-house or vendor-supplied funds 
transfer systems will need to make significant automation changes to 
send and receive the new format. The Board recognizes that many large 
depository institutions today use vendor-provided or in-house developed 
software to participate in CHIPS and S.W.I.F.T. Because these 
institutions are familiar with formats similar to the expanded format 
adopted for Fedwire and have already adopted interfaces with internal 
systems to accommodate these similar formats, it is assumed that the 
conversion effort for these institutions will be somewhat reduced.
    The Federal Reserve Banks provide software to approximately 7,900 
depository institutions that access Fedwire through 
Fedline<Register>.<SUP>3 Fedline<Register> institutions will be 
somewhat less affected as the Fedline<Register> software enhancements 
required to implement the expanded format will be provided by the 
Federal Reserve Banks; however, Fedline<Register> participants will 
require substantial education and training to become familiar with the 
new format. In addition, those institutions with back-office systems 
that interface with Fedline<Register> may need to modify such systems 
to support the new format.

    \3\Fedline<Register> is the Federal Reserve's proprietary 
software package for personal computers that is used by low-to-
medium volume Fedwire participants to access Federal Reserve 
services electronically.
---------------------------------------------------------------------------

    In its December 1993 notice, the Board proposed that the expanded 
format be implemented by late 1996. Commenters generally were 
supportive of a late 1996 implementation completion date; however, many 
commenters requested that the Computer Interface Protocol 
Specifications (CIPS) be published in mid-1994, at least 18 months in 
advance of conversion. Many commenters requested extension of the 
implementation date to late 1997. Twelve commenters were concerned that 
the proposed schedule was too ambitious because banks need to devote 
resources to support other funds-transfer-related initiatives, such as 
electronic tax collection and anti-money laundering rules, as well as 
implementation of the new Fedwire book-entry securities software and 
expansion of the Fedwire funds transfer operating hours. Commenters 
also noted that depository institution resources will be constrained by 
internal projects, such as mergers and/or acquisitions, product 
development, and application maintenance during the same period. A few 
commenters specifically requested that the Board delay expansion of the 
Fedwire funds transfer operating hours until the new format has been 
implemented fully.
    Upon careful consideration of the comments received, the Board 
believes that the burden of converting to an expanded format can be 
lessened somewhat by extending the completion date to year-end 1997. 
The Federal Reserve Banks plan to complete software development efforts 
and conduct preliminary internal testing of the revised Fedwire 
software by January 1996, followed by three months of testing with 
selected computer-interface and Fedline depository institutions. The 
full population of on-line depository institutions will conduct testing 
from April 1996 through December 1997. This should allow sufficient 
time for the Federal Reserve Banks to make necessary changes both to 
the Fedwire funds transfer system and Fedline<Register> software, and 
for the industry to incorporate and fully test the software changes 
that must be made to the funds transfer, customer delivery, and back-
office processing systems used by depository institutions.
    The Board understands the industry's desire to obtain the CIPS 
document, which details software and technical requirements, and 
installation and certification testing guidelines, well in advance of 
the beginning of the conversion period. CIPS for the new format, which 
should be used by depository institutions as a basis for modifying 
their funds transfer software, will be published in July 1995, six to 
nine months in advance of when Fedwire software will be made available 
for testing and one year in advance of the beginning of the conversion 
period. As phase one of the conversion period will last one year, there 
should be sufficient time in the schedule to accommodate those 
depository institutions that require at least an 18-month lead time to 
incorporate the CIPS into their systems. [[Page 116]] 
    Several commenters urged the Federal Reserve Banks to increase 
availability of test systems and resources, extend the testing period, 
and provide a dedicated test facility for vendors. The success of the 
CHIPS format conversion was credited largely to robust testing. The 
Board recognizes that a successful and smooth transition to a new 
Fedwire format will require the allocation of significant testing 
resources because every depository institution using an electronic 
connection will be required to bring new or substantially modified 
software into the production environment. The Federal Reserve Banks 
plan to provide increased testing resources and business support to 
depository institutions and vendors during the testing and conversion 
period.
    The revised software that supports the expanded Fedwire format, 
including both the send and receive functions, will be made available 
beginning January 1996, when selected depository institutions will be 
requested to participate in the Federal Reserve Banks' internal 
certification of the Fedwire software. Upon completion of internal 
certification of the software, the new Fedwire software that supports 
the new format will be made available for testing beginning April 1996 
for on-line depository institutions with early conversion dates.
    The testing phase for depository institutions with computer-
interface connections will encompass two steps: application software 
certification and implementation testing. Fedline<Register> software 
will be certified by the Federal Reserve Banks prior to its 
distribution to depository institutions. Vendors and depository 
institutions that have developed in-house computer-interface funds 
transfer systems will be required to demonstrate that their software 
will accommodate the new Fedwire format. All computer-interface 
depository institutions will be required to successfully complete pre-
production implementation tests, that is, tests that simulate a normal 
processing day and demonstrate that the institution can meet all of the 
CIPS requirements. Vendors that have completed national protocol 
certification will be given access to the depository institution test 
system.
    The Federal Reserve Banks will work closely with depository 
institutions to schedule and manage the timing of depository 
institution conversions. If not carefully managed, individual 
conversion delays could result in overall schedule delays. In late 
1995, the local Federal Reserve Banks will contact depository 
institutions to develop a conversion schedule. It is important for each 
depository institution to work with its local Federal Reserve Bank to 
determine appropriate dates for its conversion of the receive function 
during phase one and the send function during phase two as only a 
limited number of depository institutions will be able to schedule 
conversions on any given date. A limited number of depository 
institutions that meet specific, stringent certification requirements 
will be permitted to schedule a same-day conversion of the send and 
receive functions on the first day of the send period.
    Phase one of the implementation, during which participants convert 
from receiving the current format to receiving the new format, will 
begin in July 1996 and end May 23, 1997. In this phase, Fedwire 
software will accept only the current format but will deliver in the 
format the receiver is capable of processing. At the end of phase one, 
all participants will be required to have the ability to receive the 
new format, except those specifically certified to convert both the 
send and receive functions on the first day of phase two.
    A stabilization period of four weeks (Saturday, May 24 through 
Friday, June 20, 1997) will be provided at the conclusion of phase one. 
If any depository institution has failed to convert the receive side 
during a previously scheduled date in phase one, it will be permitted 
to complete implementation of the receive function during the 
stabilization period.
    Phase two of the implementation, during which participants convert 
from sending the old format to sending the new format, will begin 
Monday, June 23, 1997. This date also is the designated cutover date 
for those depository institutions that have certified software and 
recovery capabilities for same-day conversion of the send and receive 
functions. Beginning on the first day of the send period, the Federal 
Reserve Banks will no longer deliver funds transfer messages to the 
receiver in the old format; every participant will be required to 
accept the new format. Until a sender begins sending the new format, 
Fedwire will accept the sender's messages and convert them to the new 
format for delivery to the receiver. Phase two will end Monday, 
December 29, 1997, at which time all participants will be required to 
both send and receive the new format.
    The following table summarizes the schedule for implementation of 
the new Fedwire funds transfer format.

------------------------------------------------------------------------
                                                    Start               
                      Task                           date      End date 
------------------------------------------------------------------------
Distribute CIPS.................................       7/95  ...........
Selected Depository Institution Participation in                        
 Testing........................................       1/96         4/96
Full Population Depository Institution Testing--                        
 Receive and Send Functions.....................       4/96        12/97
Phase I--Convert Receive Function...............     7/1/96      5/23/97
Stabilization Period............................    5/24/97      6/20/97
Same-day Conversions............................    6/23/97      6/23/97
Phase II--Convert Send Function.................    6/23/97     12/29/97
------------------------------------------------------------------------

Expanded Operating Hours

    In February 1994, the Board approved expansion of the Fedwire on-
line funds transfer operating hours to 18 hours per day from the 
current 10 hours per day, beginning in early 1997 (59 FR 8981, February 
24, 1994). The opening time will be revised from the current 8:30 a.m. 
ET to 12:30 a.m. ET, but the closing time will remain unchanged at 6:30 
p.m. ET. Over time, longer Fedwire funds transfer hours will have 
public policy benefits because the availability of final payment 
capabilities during the early morning hours can strengthen interbank 
settlements and contribute to reductions in Herstatt risk through 
innovations in payment and settlement practices.
    The Board has considered commenters' requests to delay 
implementation of expanded funds transfer operating hours until the new 
format has been implemented fully. The Board recognizes that although 
participation is voluntary, many depository institutions believe that 
market forces would require their participation during the expanded 
funds transfer operating hours. Some commenters stated that they may 
need to implement software modifications to shorten back-office posting 
and processing cycles in order to take full advantage of the expanded 
funds transfer operating hours. These commenters indicated that the 
allocation of bank resources to implement a new format may contend 
directly with efforts to modify software to accommodate expanded 
Fedwire funds transfer operating hours. After considering these and 
other issues, the Board has delayed implementation of the 12:30 am ET 
opening time for the Fedwire funds transfer service until late 
[[Page 117]] 1997.\4\ (See notice elsewhere in today's Federal 
Register.)

    \4\An exact date for expanded funds transfer operating hours 
will be announced approximately one year prior to the effective 
date.
---------------------------------------------------------------------------

Usefulness to Law Enforcement

    On August 31, 1993, the Treasury requested comment on a proposed 
regulation that would require financial institutions to include certain 
information in payment orders that they send (58 FR 46021, August 31, 
1993) (the Travel Rule). Law enforcement agencies have indicated that 
the inclusion of complete transfer party information in the payment 
order will be particularly useful in tracing the proceeds of illegal 
activities and will assist in identifying and prosecuting persons 
involved in such illegal activities.
    Commenters generally acknowledged that the Fedwire format must be 
expanded to accommodate the information desired for law enforcement 
purposes, although many did not agree this information should be 
carried in the message, because the information could be obtained from 
the depository institutions that are parties to the transfer. Further, 
commenters stressed that the Travel Rule should not require complete 
transfer party information in Fedwire transfers until such time as the 
format can accommodate its inclusion. The Treasury has considered these 
concerns and has revised the final Travel Rule to accommodate the 
limitations of the current Fedwire format. In particular, the Travel 
Rule as adopted does not require that Fedwire transfers include the 
address of the transmitter until completion of the implementation of 
the expanded format. (See notice elsewhere in today's Federal 
Register.)

Description of the Expanded Fedwire Format

    The expanded Fedwire format includes a comprehensive set of the 
elements commonly used in the origination and receipt of payment 
orders. It is similar to the CHIPS and S.W.I.F.T. formats and provides 
an expanded message length and variable-length fields. The expanded 
format is modeled on the CHIPS format and only differs when necessary 
to accommodate technical processing requirements specific to Fedwire or 
to delete technical processing requirements specific to CHIPS. 
Additional fields have been defined, and the fields that carry payment 
details are larger than those in the current Fedwire format. The larger 
fields permit the inclusion of more complete information about the 
parties to a transfer and allow space for additional payment 
information. There is adequate space to provide the name, account 
number or other identifying number, and three lines of address 
information for each party to the transfer.
    The expanded format differs from the current Fedwire format in 
several significant ways: messages are not required to be fixed length 
but may vary in length; maximum message length is significantly 
expanded; the number and size of fields have significantly increased; 
and field tags (codes that identify the type of information a field may 
carry) are numeric rather than alpha. Numeric tags are used because 
they are more flexible than letter groupings and they facilitate the 
mapping of information between transfer systems. The format is highly 
structured--a field tag is used to designate the contents of every 
field in the message. Together, these changes provide the ability to 
translate fully and consistently payment order information into 
discrete fields, which will permit Fedwire participants to automate 
more fully payment order processing.
    The presentation of routing and transfer information in the 
expanded format has been reorganized to follow more closely the path of 
a message from sender to receiver. The expanded format presents the 
sending bank routing number and sending bank name before the receiving 
bank routing number and receiving bank name. The expanded format also 
reorganizes transfer party information, presenting the flow of funds 
and information from the perspective of the receiver. That is, the 
intermediary bank, beneficiary bank and beneficiary information fields 
precede the originator, originating bank, and instructing bank 
information fields.\5\ The expanded format's presentation of routing 
and transfer party information is consistent with the presentation of 
similar data in the CHIPS format.

    \5\The terminology used here generally conforms to the 
definitions in Article 4A of the Uniform Commercial Code; however, 
the field names in the proposed format use the term ``financial 
institution'' instead of bank. Terminology related to nonbank 
financial institutions conforms to the definitions in the wire 
transfer recordkeeping rule adopted by the Treasury and the Board. 
(See notice elsewhere in today's Federal Register.)
---------------------------------------------------------------------------

    Commenters generally agreed with the format as proposed; however, a 
few commenters suggested the format be revised. Suggested modifications 
included: eliminate the requirement for punctuation and disallow the 
dollar sign in the amount field; provide quality edits for beneficiary 
account number field; and activate charges tag. Commenters also 
requested that the new format retain the existing alpha tags; include 
descriptive titles with numeric tags; and include special tags for 
service and drawdown messages. Further, commenters identified the 
potential for using Fedwire to effect tax payments and Electronic Data 
Interchange (EDI). One commenter identified circumstances, when mapping 
from the old format to the new format, that the potential for 
truncation may exist.
    Some commenters indicated that punctuation and dollar sign are 
unnecessary in the amount field because the software depository 
institutions use to send and receive Fedwire funds transfer messages 
has the capability to display Fedwire information in a manner that is 
inherently more ``user friendly'' than the way the same information may 
be recorded in the Fedwire format. For example, it is not necessary for 
the Fedwire format to require inclusion of punctuation and the dollar 
sign because both the sending and receiving banks' software can append 
these attributes when displaying the information on screens or reports. 
Further, as the CHIPS format does not include punctuation and dollar 
sign in the amount field, the inclusion of these characters in the 
Fedwire funds transfer format introduces inconsistency between the 
formats. Therefore, the format the Board has adopted does not 
accommodate punctuation or a dollar sign in the amount field.
    One commenter requested that Fedwire perform quality edits on 
certain fields to ensure the contents conform to the provisions of the 
Travel Rule; for example, the beneficiary field should be edited to 
ensure account number has been included. The Board believes it would be 
appropriate to edit for the inclusion of information in certain 
required fields; however, it would be infeasible to edit and reject 
messages based on the meaningfulness of the data in those fields. 
Specific editing criteria for field contents will be provided in the 
CIPS distributed in mid-1995.
    One commenter requested that the charges tag, which was reserved 
for future use, be activated now to allow a sender to instruct a 
receiver, when appropriate, to deduct charges and expenses from the 
principal amount. The commenter noted that activation of the tag would 
increase compatibility between payment systems because a similar field 
currently is provided in both the CHIPS and S.W.I.F.T. formats. 
[[Page 118]] The charges tag has been activated as an optional 
field.\6\

    \6\Article 4A-302(d) of the Uniform Commercial Code states that 
unless instructed by the sender, the receiving bank may not obtain 
payment of its charges for services and expenses in connection with 
the execution of the sender's payment order by issuing a payment 
order in an amount equal to the amount of the sender's order less 
the amount of charges, and may not instruct a subsequent receiving 
bank to obtain payment of its charges in the same manner.
---------------------------------------------------------------------------

    Some commenters expressed concern that the alpha tags will be 
replaced with numeric tags and that the numeric tags will not 
automatically display descriptive titles. The Board believes that, to 
facilitate the use of the format by depository institution staff and 
customers, the software resident at the sending and receiving 
institutions should have the capability to translate numeric tags into 
descriptive field tag titles on screens, advices and reports. The 
screens provided by the Fedline<Register> software, as well as paper 
advices and reports provided by the Federal Reserve Banks, will include 
descriptive field tag titles; however, these titles will not be 
included in the formatted messages transmitted over communication 
lines.
    One commenter noted that the proposal did not address all the 
different types of messages that could be sent over Fedwire and 
requested clarification. The Board recognizes that use of a uniform 
format as a basis for all types of Fedwire messages, including drawdown 
messages, service messages, and other non-value messages, provides a 
certain level of standardization essential to automating more fully 
back-office processing. Fedwire funds-related messages, that is, 
drawdown messages, service messages, and other non-value messages, will 
be subject to the new format. A new field tag(s) will be defined for 
use with drawdown and service messages; the CIPS document will detail 
the specifics of formatting these types of non-value messages.
    A depository institution also may use the Fedwire funds transfer 
system to communicate a notice of nonpayment for a check that will be 
returned from a paying bank to a depositary bank as required under 12 
CFR 229.33. Such a message is commonly called a return item 
notification, and is processed through the Fedwire funds transfer 
system using a unique transaction type code and message format. The 
Board does not plan to change the check notice of nonpayment message 
format to the new structure because this business generally is 
conducted separately from the funds transfer business and utilizes 
different back-office systems. Changing the check return notification 
message format would require modification of the associated back-office 
systems and would impose costs on depository institutions without 
commensurate benefits.
    Some commenters believed that the new format should accommodate 
electronic tax collection initiatives, and one commenter specifically 
requested that Fedwire incorporate the ACH TXP (tax payment) format. 
One commenter prepared a detailed mapping recommendation. The Fedwire 
and ACH systems differ significantly with respect to the method of 
processing and the form of the data. While the Fedwire format is not 
able to substitute directly for any of the ACH payment formats, 
including the TXP format, the expanded format contains sufficient space 
to carry the details of a tax payment as currently defined by the 
Internal Revenue Service. Further, the Fedwire system may be used to 
make certain tax payments and may serve in an emergency back-up 
capacity to forward a tax payment that would normally flow through ACH; 
however, these tax payments must conform to the standard format used 
for Fedwire funds transfers. The Federal Reserve Banks will continue to 
study the evolution of the use of Fedwire to make tax payments; for 
example, the Federal Reserve Banks plan to incorporate a unique product 
code in the current format to assist depository institutions in 
structuring information within a designated field tag to facilitate 
this type of payment. The new format will incorporate this new tax 
payment product code, designated field tags and associated voluntary 
structuring, which will be described more fully in the CIPS document.
    A few commenters indicated that the new format should accommodate 
EDI capability; however, one commenter strongly objected to the use of 
Fedwire for EDI, noting that other suitable mechanisms already exist. 
The Board believes it is important that an expanded format recognize 
the need for certain information to travel with the payment. Although 
the expanded format may afford depository institutions with some 
ability to exchange EDI information, certain non-payment related 
activity is better suited to other types of communication systems.
    One commenter was concerned that some information may be truncated 
when mapping from the current format to the expanded format. This may 
occur because the space allocated in the third-party text portion of 
the current format may contain up to seven field tags or may be used 
for just one field tag. Space is allocated more discretely in the new 
format, so when only one field tag is used in the old format it is 
possible to exceed the number of available characters for the 
equivalent field in the new format. During the transition to the new 
format, the Fedwire software will map the excess characters into a new 
field defined to carry overflow information. A complete description of 
this mapping function will be provided in the CIPS document.
    Several other commenters requested clarification of some technical 
characteristics of the format. These clarifications will be addressed 
in the CIPS documentation.

Details of the New Format

    The expanded format can accommodate much longer messages than the 
current Fedwire format. For example, messages sent by a depository 
institution to the Federal Reserve Bank may contain approximately 1700 
characters, compared to approximately 600 characters under the current 
Fedwire format. Intercepts--messages returned to the sending depository 
institution by Fedwire--and messages delivered by the Federal Reserve 
Bank to a receiving depository institution may contain approximately 
1800 characters in the expanded format, compared to approximately 700 
characters today. Message length varies due to the information appended 
during processing by the Federal Reserve Banks.
    Field size in the new format has been increased and the field 
structure has changed. Each field has two parts: a tag that identifies 
the type of information a field may carry and elements that identify 
the specific piece of data within the field. The field tag must be one 
of the numeric codes designated for that purpose and the elements must 
be depicted in a specific order within the field. In general, elements 
are pieces of information that commonly follow a particular field tag, 
including but not limited to identifying information such as name, 
address, and account number. Valid elements are defined for each field 
tag. For example, the originator field has a field tag of [5000] that 
will be followed by elements, such as account number, name and address.
    The number of field tags in the new format is expanded greatly and 
incorporates the complete set of payment-related tags utilized by the 
current Fedwire format. The alpha tags in the current Fedwire format 
have been translated into numeric codes in the expanded format. For 
example, the beneficiary information field tag, denoted by BNF= in the 
current format, is tag [4200] in the expanded format. (The Glossary 
includes the field tag definitions and the Appendix lists the 
[[Page 119]] set of field tags.) Additional field tags have been 
defined to denote each of the standard fields in a message, including 
routing and technical information. For example, the IMAD (Input Message 
Accountability Data), which is assigned to a specific field position in 
the current Fedwire format, follows field tag [1520] in the expanded 
format.
    Elements, the information that follows a field tag, must be 
presented in a specific order within a field. The information either 
may be free form and of variable length, such as address, or may 
require a specific format, such as the business function code (product 
code), which must contain one of the eight defined acronyms. Each 
element within a field is allocated a specific amount of space; some 
elements are fixed in length, such as sender routing number, while 
others are variable in length, such as address. A delimiter element (*) 
always will follow a variable length element to denote the end of the 
element. No delimiter will follow a fixed length element. The elements 
convey information in a specific order and a combination of identifier 
code and field position is used to identify such information as account 
number. For example, the current format allows the identifier code, in 
this case /AC- (account number) to be used somewhere in the field 
following the beneficiary field tag, BNF=.../AC-123. In the new format, 
the beneficiary field tag [4200] may be followed by up to twelve 
elements: for example, the one character identifier code (first 
element); the identifier specified by the code, in this case an account 
number (second element); a delimiter, which is always an asterisk 
(third element); the beneficiary name (fourth element); and another 
delimiter (fifth element), such as [4200]D123*SMITH*. The identifier 
code is always the first element and identifies the type of number that 
follows it, in this case ``D'' represents account number. The 
identifier codes are defined in the Glossary.
    Although there are a large number of field tags defined in the new 
format, it is not necessary to use every tag in each message. The 
majority of the messages that a depository institution will send--
transfers where the originator is an account holder of the sending bank 
and the beneficiary is an account holder of the receiving bank--can be 
accommodated in a set of nine basic tags, depending upon how much 
originator and beneficiary information is provided. If the bank 
accepting the payment order from the originator is the institution 
sending the payment order to the Federal Reserve Bank, then it can be 
identified by routing number and short name in the field following the 
Sender FI tag [3100]. If the bank accepting the payment order for the 
beneficiary is the institution receiving the payment order from the 
Federal Reserve Bank, then it can be identified by routing number and 
short name in the field following the Receiver FI tag [3400].
    For example, John Doe is sending $7,000 to his aunt, Sally Jones, 
who has an account at Bank Seven. John decides to send the money from 
his deposit account at Bank Away. John asks his account officer at Bank 
Away to send the money to his aunt at Bank Seven. The account officer 
has John's name, address, and account number on file, and asks John to 
provide the same information for his aunt. John provides this 
information to his bank.
    John's account officer at Bank Away prepares a payment order and 
forwards it to the funds transfer area for transmission over Fedwire:

Amount: $7,000
Date: January 5, 1995
From: John Doe, account 6666123456, One Wayward Avenue, Watertown, MD
To: Bank Seven, Chicago, ABA 079999999, for further credit to account 
899899, Sally Jones, 1920 Flapper Lane, Chicago, IL.

    Bank Away's funds transfer area accepts the account officer's 
payment order and prepares a corresponding payment order to send over 
Fedwire (in bold):

------------------------------------------------------------------------
            Description                          Tag/Elements           
------------------------------------------------------------------------
Sender Supplied Information........  [1500]MISCINFOHERE                 
Type/Sub-type......................  [1510]1000                         
IMAD...............................  [1520]0105E9999999000001           
Amount.............................  [2000]700000                       
Sender FI..........................  [3100]059999999AWAY*               
Sender Reference...................  [3320]9999999999999999             
Receiver FI........................  [3400]079999999BANKSEVEN*          
Business Function Code.............  [3600]CTR                          
Beneficiary........................  [4200]D899899*SALLY JONES* 1920    
                                      FLAPPER LA* CHICAGO, IL*          
Originator.........................  [5000]6666123456*JOHN DOE* 1       
                                      WAYWARD AVE* WATERTOWN, MD*       
------------------------------------------------------------------------

    The expanded format also will provide ample space to include 
identifying information in a payment order to facilitate financial 
institution compliance with Treasury's Travel Rule. For example, the 
field following the originator tag [5000] has sufficient space, up to a 
maximum of 186 characters (including the tag) to include the 
originator's account number, name, and address. The expanded format 
also provides more space to identify the bank that accepted the payment 
order from the originator; the bank routing number, name and address 
can be described in the field following originator's financial 
institution tag [5100], up to a maximum of 186 characters (including 
the tag). The current format only provides a maximum of 61 characters 
to identify both the originator and the originating bank.
    Some Fedwire messages will be much larger and use more than the 
basic set of nine field tags to describe the parties to the transfer. 
For example, in cases where the originator and/or the beneficiary is a 
customer of a financial institution that is not a Fedwire participant, 
additional tags will be used to identify the originator's financial 
institution, the beneficiary's financial institution, and potentially 
also the instructing financial institution and the intermediary 
financial institution.
    If the customer of the originating bank is a nonbank financial 
institution, the originator tag [5000] and originator's financial 
institution tag [5100] can be used to identify the transmittor and 
transmittor's financial institution, respectively. In this case, the 
field following the originator tag [5000] can be used to reflect the 
transmittor's account number, name and address. Information identifying 
the transmittor's financial institution--the nonbank financial 
institution that accepts the transmittal order from the transmittor--
can be included in the field following the originator's financial 
institution tag [5100]. If the transmittor's financial institution 
forwards the transmittal order to a financial institution that is not a 
Fedwire participant but utilizes a correspondent to access Fedwire, 
that institution's identifying information, such as routing number and 
name, may follow the instructing financial institution tag [5200]. If 
the beneficiary's financial institution is not a Fedwire participant, 
the sender may direct the payment order to a correspondent bank that 
maintains a relationship with the beneficiary's financial institution. 
In such a case, the identifying information, such as routing number and 
name of the beneficiary's financial institution, may follow the 
beneficiary's financial institution tag [4100]. The correspondent will 
be identified in the field following the receiver financial institution 
tag [3400]. [[Page 120]] 
    In the example below, John Doe is sending money to his aunt, Sally 
Jones. The money is being sent from his money market mutual fund 
account at Big Broker/Dealer, a customer of Ultimate Bank & Trust, 
which is a respondent of Bank Away, a Fedwire participant. Sally Jones 
is a customer of Local Credit Union, a respondent of Bank Seven. 
Further, Sally requests that John include instructions for the credit 
union to call her when the money is received. John's account officer at 
Big Broker/Dealer has John's name, address, and account number on file. 
John provides his aunt's name and address, but is unaware of her 
account number.
    Big Broker/Dealer prepares a transmittal order and forwards it to 
its bank, Ultimate Bank & Trust.

Amount: $7,000
Date: January 5, 1995
From: Our Account 767676, on behalf of our customer John Doe, account 
MMMF123456, One Wayward Avenue, Watertown, MD
To: Bank Seven, Chicago, ABA 079999999; for further credit to Local CU, 
808 Watertower Center, Chicago, IL 60604, ABA 271011111; to credit its 
customer Sally Jones, 1920 Flapper Lane, Chicago, IL
Instructions: Phone advice--Ms. Jones (312)555-1212.

    Ultimate Bank & Trust accepts Big Broker/Dealer's transmittal 
order, but is not a Fedwire participant, so it prepares a corresponding 
payment order, adding the address of Big/Broker Dealer from its 
customer file, and forwards the payment order to Bank Away, its 
correspondent. Bank Away accepts Ultimate Bank & Trust's payment order 
and prepares a corresponding payment order to send over Fedwire (in 
bold):

------------------------------------------------------------------------
            Description                          Tag/Elements           
------------------------------------------------------------------------
Sender Supplied Information........  [1500]MISCINFOHERE                 
Type/Sub-type......................  [1510]1000                         
IMAD...............................  [1520]0105E9999999000001           
Amount.............................  [2000]700000                       
Sender FI..........................  [3100]059999999AWAY*               
Sender Reference...................  [3320]9999999999999999             
Receiver FI........................  [3400]079999999BANKSEVEN*          
Business Function Code.............  [3600]CTR                          
Beneficiary's FI...................  [4100]F271011111*LOCAL CU* 808     
                                      WATERTOWER CENTER* CHICAGO, IL    
                                      60604*                            
Beneficiary........................  [4200]DUNKNOWN*SALLY JONES* 1920   
                                      FLAPPER LA* CHICAGO, IL*          
Originator.........................  [5000]NMMMF123456*JOHN DOE* 1      
                                      WAYWARD AVE* WATERTOWN, MD*       
Originator's FI....................  [5100]D767676*BIGBROKER/DEALER* 222
                                      CAMDEN YARDS CIRCLE* BALTIMORE,   
                                      MD*                               
Instructing FI                       [5200]F058888888*ULTIMATE*         
FI to FI--Beneficiary's FI Advice..  [6310]PHN ON RECEIPT* CALL MS JONES
                                      312-555-1212*                     
------------------------------------------------------------------------

    The beneficiary tag [4200] and beneficiary's financial institution 
tag [4100] also can be used to identify the recipient and recipient's 
financial institution when the person to be paid by the transmittal 
order is the customer of a nonbank financial institution.
    In the example above, if John Doe had sent the money to his aunt in 
care of a currency exchanger, Money Swap, which also is a customer of 
Bank Seven, instead of the credit union, then the payment order sent to 
Fedwire would reflect the account number, name and address of Money 
Swap following the Beneficiary's FI tag [4100].
    The expanded format also accommodates inclusion of complete 
information received in an international (S.W.I.F.T. or CHIPS) transfer 
that must be forwarded over Fedwire. For example, on January 5, 1995, 
First Bronx NY receives a S.W.I.F.T. message from Black Forest Bank, 
Munich (S.W.I.F.T. identifier BBFBKDEZZ) to pay Cowboy Trust, Dallas 
for further credit to T. Edwards, account 123456 at the Rodeo Road 
Branch in Austin. The S.W.I.F.T. message indicates that Franz Mousse, 
doing business as Steak Palace, Maximillianstrasse 38, Munich, is 
paying T. Edwards $34,000 US, $10,000 on invoice TT33 for two cases of 
Texas T's Bar-B-Q sauce and $24,000 as a franchise fee for use of the 
Texas T's Secret Recipe. Black Forest Bank includes an instruction that 
states ``Pay immediately. Do not deduct any related fees from the 
transfer amount--charge fee separately.'' First Bronx prepares a 
corresponding transmittal order and forwards it over Fedwire (in bold):

------------------------------------------------------------------------
          Description                         Tag/Elements              
------------------------------------------------------------------------
Type/Sub-type.................  [1510]1000                              
IMAD..........................  [1520]0105B9999999000001                
Amount........................  [2000]3400000                           
Sender FI.....................  [3100]029999999FIRST BRONX NY*          
Sender Reference..............  [3320]9999999999999999                  
Receiver FI...................  [3400]119999999COWBOYBANK*              
Business Function Code........  [3600]CTR                               
Intermediary FI...............  [4000]F029999999FIRST BRONX NY*         
Beneficiary's FI..............  [4100]F119999999*COWBOYBANK* RODEO ROAD 
                                 BRANCH* AUSTIN, TX*                    
Beneficiary...................  [4200]D123456*T. EDWARDS*               
Originator....................  [5000]DUNKNOWN*FRANZ MOUSSE* DBA STEAK  
                                 PALACE* MAXIMILLIANSTRASSE 38* MUNICH, 
                                 GERMANY*                               
Originator's FI...............  [5100]BBFBKDEZZ*BLACKFOREST BK* MUNICH, 
                                 GERMANY*                               
Originator to Beneficiary       [6000]PAY T. EDWARDS $34,000 US,*       
 Information.                    $10,000 INV# TT33 2 CASES TEXAS T'S*   
                                 BAR-B-Q SAUCE, $24,000 FRANCHISE FEE*  
                                 FOR TEXAS T'S SECRET RECIPE*           
FI to FI--Receiving FI          [6100]PER BLACK FOREST BANK* PAY        
 Information.                    IMMEDIATELY. DO NOT DEDUCT ANY* RELATED
                                 FEES FROM THE TRANSFER* AMOUNT--CHARGE 
                                 FEE SEPARATELY*                        
------------------------------------------------------------------------

Competitive Impact Analysis

    The Board believes that this proposal will have no adverse effect 
on the ability of other service providers to compete effectively with 
the Federal Reserve Banks in providing similar services. Specifically, 
the Board believes that implementing the expanded format will have only 
a minimal effect on the operations of the CHIPS payment system. That 
is, CHIPS settlement participants will need to utilize the new format 
when sending and receiving settlement transfers through the Federal 
Reserve Bank of New York; however, [[Page 121]] these same depository 
institutions are also Fedwire participants and will utilize the new 
format to send and receive all Fedwire traffic.
    The Board also believes that the adoption of the expanded format 
will increase compatibility among CHIPS, S.W.I.F.T. and Fedwire. 
Increased compatibility facilitates the mapping of transfer information 
from one format to another when a payment order flows through multiple 
intermediary banks that use different funds transfer systems. Enhanced 
compatibility also broadens the range of choices that sending and 
intermediary financial institutions have when selecting a funds 
transfer system.

    By order of the Board of Governors of the Federal Reserve 
System, December 21, 1994.
William W. Wiles,
Secretary of the Board.

                                                    Glossary                                                    
----------------------------------------------------------------------------------------------------------------
      New format             Current format                                 Definition                          
----------------------------------------------------------------------------------------------------------------
Acceptance time stamp   ........................  Field tag used to indicate the date and time that the Fedwire 
 [1110].                                           application accepted the transfer; also includes the Fedwire 
                                                   application ID.                                              
Adjustment [3000].....  ........................  Field tag used to carry the as-of date and reason for an      
                                                   adjustment; supplied by the Federal Reserve Bank granting the
                                                   adjustment.                                                  
Advice code...........  ........................  An element consisting of a three character code, used in the  
                                                   FI to FI advice field to identify the method to be used to   
                                                   notify a party of the receipt of funds:                      
                        ........................  LTR  Letter                                                   
                        ........................  PHN  Phone                                                    
                        ........................  TLX  Telex                                                    
                        ........................  WRE  Wire                                                     
Amplifying advice.....  ........................  Information provided in the FI to FI advice fields used to    
                                                   facilitate the delivery of the payment notification, such as 
                                                   phone number and contact name.                               
Amount [2000].........  ........................  Field tag used to indicate the amount of the transfer. (Note: 
                                                   There is an application edit that limits the transfer amount 
                                                   to one cent less than $1 billion.)                           
Beneficiary [4200]....  BNF=                      Field tag used to identify the person to be paid by the       
                                                   beneficiary's financial institution.                         
Beneficiary's           BBK=                      Field tag used to identify the financial institution          
 financial institution                             identified in the Fedwire message in which an account of the 
 [4100].                                           beneficiary is to be credited or which otherwise is to make  
                                                   payment to the beneficiary.                                  
Business function       Product Code              In the current format, a product code is the three character  
 [3600].                                           code, followed by a slash, that identifies the purpose of the
                                                   transfer. In the new format, the business function field tag 
                                                   is used to carry the three character code.                   
                        ........................  BTR Bank transfer--beneficiary is a bank.                     
                        ........................  CTR Customer transfer--beneficiary is a nonbank.              
                        ........................  CKS Check same-day settlement.                                
                        ........................  DEP Deposit to sender's account.                              
                        ........................  DRW Drawdown.                                                 
                        ........................  FFR Fed funds returned.                                       
                        ........................  FFS Fed funds sold.                                           
                        ........................  IRS IRS tax payment.                                          
Charges [3700]........  ........................  Field tag used by the originator's financial institution to   
                                                   instruct a beneficiary's financial institution to deduct     
                                                   charges, if appropriate.                                     
Delimiter.............  ........................  An asterisk (*) used to mark the end of variable length data. 
Element...............  ........................  A specific piece of information carried in a field, which     
                                                   further identifies or defines the contents of a field. For   
                                                   example, the beneficiary field generally includes elements   
                                                   such as name and address.                                    
Error [1130]..........  ........................  Field tag used by the Federal Reserve Bank returning a Fedwire
                                                   transfer to the sender; includes an error code and           
                                                   description, such as ``E185 INVALID TYPE/SUBTYPE.''          
FI to FI [6100] to      BBI=                      Financial institution to financial institution information    
 [6500].                                           field tags used to identify miscellaneous information        
                                                   pertaining to the transfer. In the new format, the FI to FI  
                                                   tags include information that commonly follows the BBI= tag  
                                                   and the advice method components of the IBK=, BBK=, and BNF= 
                                                   tags in the current format. The FI to FI tags are:           
                        ........................  Receiver FI information [6100].                               
                        ........................  Intermediary FI information [6200].                           
                        ........................  Intermediary FI advice info [6210].                           
                        ........................  Beneficiary's FI information [6300].                          
                        ........................  Beneficiary's FI advice info [6310].                          
                        ........................  Beneficiary method of payment [6320].                         
                        ........................  Beneficiary information [6400].                               
                        ........................  Beneficiary advice info [6410].                               
                        ........................  FI to FI information (generic) [6500].                        
Field.................  Field                     The portion of a message extending from a field tag to, but   
                                                   not including, another field tag or the end of the message. A
                                                   field begins with a tag and, in the new format, is followed  
                                                   by one or more individual data items called elements.        
Field tag.............  Field tag                 In the current format, the field tag denotes the beginning of 
                                                   third-party information, and is composed of four characters  
                                                   in the form aaa=, where ``a'' is a letter and an equals sign 
                                                   denotes the end of the tag. There are nine field tags in the 
                                                   current format.                                              
                        ........................  In the new format, the field tag denotes the beginning of any 
                                                   field (except for the interface code field). The tag is      
                                                   composed of six characters in the form [nnnn], where ``n'' is
                                                   a number. There are 33 field tags in the new format.         
Identifier code.......  ........................  The first element following a transfer party tag; a one       
                                                   character code that defines the type of identifier that      
                                                   follows it:                                                  
                        ........................  N  Nonbank (e.g. driver's license).                           
[[Page 122]]                                                                                                    
                                                                                                                
                        ........................  D  Account number (e.g. deposit acct).                        
                        ........................  B  Bank Identifier Code (BIC/SWIFT).                          
                        ........................  C  CHIPS UID Code.                                            
                        ........................  F  Routing number.                                            
Identifier............  ........................  A variable-length element that identifies a party to a        
                                                   transfer, such as an account number or routing number. The   
                                                   identifier follows the identifier code in each field tag that
                                                   identifies a party to the transfer.                          
IMAD [1520]...........  ........................  Field tag used to carry the Input Message Accountability Data.
                                                   The IMAD is established at the time the message is first     
                                                   received by a Federal Reserve Bank, and includes a date, the 
                                                   logical terminal (Lterm) associated with the interfacing     
                                                   application that sent the message to Fedwire, and the        
                                                   sequence number assigned by the interfacing application.     
Intermediary financial  IBK=                      Field tag used to identify the institution between the        
 institution [4000].                               receiver FI and the beneficiary's FI through which the       
                                                   transfer must pass.                                          
Instructing financial   INS=                      Field tag used to identify the institution other than the     
 institution [5200].                               originator's financial institution that issues a payment     
                                                   order to the sending institution.                            
Interface code........  ........................  Field used to indicate the type of communications protocol    
                                                   used by the application sending a transfer to a Federal      
                                                   Reserve Bank:                                                
                        ........................  X  FLASH.                                                     
                        ........................  Z  FRISC.                                                     
Message disposition     ........................  Field tag used to carry certain message-related control       
 [1100].                                           information. The field has four elements: format version,    
                                                   test/production code, message duplication code, and message  
                                                   status indicator.                                            
OMAD [1120]...........  ........................  Field tag used to carry the Output Message Accountability     
                                                   Data. OMAD is established at the time the message is queued  
                                                   for delivery by a Federal Reserve Bank, and includes the     
                                                   date, the logical terminal (Lterm) associated with the       
                                                   interfacing application that will receive the message from   
                                                   Fedwire, a sequence number, a time stamp, and a code         
                                                   identifying the Federal Reserve Bank delivering the message. 
Originator [5000].....  ORG=                      Field tag used to identify the sender of the first payment    
                                                   order in a funds transfer.                                   
Originator's financial  OGB=                      Field tag used to identify the financial institution to which 
 institution [5100].                               the payment order of the originator is issued.               
Originator to           OBI=                      Field tag used to identify information conveyed from the      
 beneficiary                                       originator to the beneficiary.                               
 information [6000].                                                                                            
Previous Message IMAD   ........................  Field tag used to reference the IMAD of an earlier transfer   
 [3500].                                           when the sender is returning, correcting, or otherwise       
                                                   referencing a transfer previously sent or received.          
Receiver financial      ........................  Field tag used to carry the nine-digit routing number and     
 institution [3400].                               short name of the financial institution that received the    
                                                   transfer from a Federal Reserve Bank.                        
Reference for           RFB=                      Field tag used to provide reference information that enables  
 beneficiary [3321].                               the beneficiary to identify the transfer.                    
Sender financial        ........................  Field tag used to carry the nine-digit routing number and     
 institution [3100].                               short name of the financial institution that sent the        
                                                   transfer to a Federal Reserve Bank.                          
Sender reference        ........................  Field tag used to carry the sending financial institution's   
 [3320].                                           reference number.                                            
Sender supplied         ........................  Field tag used by sender financial institution to carry the   
 information [1500].                               following three elements: user request correlation data, test/
                                                   production code, and message duplication code.               
Special handling        ........................  Field tag used by the Federal Reserve Bank to insert special  
 instruction [1140].                               handling instructions.                                       
Type/Subtype code       ........................  Field tag used to indicate the transfer type and sub-type.    
 [1510].                                                                                                        
                        ........................  Type code values:                                             
                        ........................  10  Third-party funds transfer.                               
                        ........................  15  Foreign transfer (foreign central banks and international 
                                                   agencies).                                                   
                        ........................  16  Settlement transfers.                                     
                        ........................  Sub-type code values:                                         
                        ........................  00  Transfer.                                                 
                        ........................  01  Request for reversal.                                     
                        ........................  02  Reversal of transfer.                                     
                        ........................  07  Request for reversal of prior day transfer.               
                        ........................  08  Reversal of prior day transfer.                           
                        ........................  20  As-of adjustment.                                         
                        ........................  31  Request for credit transfer (drawdown).                   
                        ........................  32  Funds transfer honoring request for credit transfer.      
                        ........................  33  Refusal to honor request for credit transfer.             
                        ........................  90  Service message.                                          
----------------------------------------------------------------------------------------------------------------


                             Appendix--New Fedwire Funds Transfer Format Field Tags                             
----------------------------------------------------------------------------------------------------------------
                                                                                Required/ Optional              
         Tag No.                           Tag description<SUP>a                           Field<SUP>b             Size<SUP>c  
----------------------------------------------------------------------------------------------------------------
None<SUP>d...................  Interface code...................................  Appended................          1
[1100]<SUP>d.................  Message disposition..............................  Appended................          9
[1110]<SUP>d.................  Acceptance time stamp............................  Appended................         18
[[Page 123]]                                                                                                    
                                                                                                                
[1120]<SUP>d.................  OMAD.............................................  Appended................         36
[1130]<SUP>d.................  Error............................................  Appended................         46
[1140]<SUP>d.................  Special handling instructions....................  Appended................         33
[1500]<SUP>d.................  Sender supplied information......................  Required................        <SUP>e18
[1510]<SUP>d.................  Type/Subtype code................................  Required................         10
[1520]<SUP>d.................  OMAD.............................................  Appended................         24
[2000]..................  Amount...........................................  Required................         24
[3000]..................  Adjustment.......................................  Optional................         14
[3100]..................  Sender FI........................................  Required................         34
[3320]..................  Sender reference.................................  Required................         23
[3321]..................  Reference for beneficiary........................  Optional................         23
[3400]..................  Receiver FI......................................  Required................         34
[3500]..................  Previous Message IMAD............................  Optional................         24
[3600]..................  Business function................................  Required................          9
[3700]..................  Charges..........................................  Optional................          9
[4000]..................  Intermediary FI..................................  Optional................        186
[4100]..................  Beneficiary's FI.................................  Optional................        186
[4200]..................  Beneficiary......................................  Optional................        191
[5000]..................  Originator.......................................  Required................        186
[5100]..................  Originator's FI..................................  Optional................        186
[5200]..................  Instructing FI...................................  Optional................        186
[6000]..................  Originator to beneficiary information............  Optional................        150
                          FI to FI:                                                                             
[6100]..................  Receiver FI information..........................                                     
[6200]..................  Intermediary FI information......................                                     
[6210]..................  Intermediary FI advice information...............                                     
[6300]..................  Beneficiary's FI information.....................  Optional................        222
[6310]..................  Beneficiary's FI advice information..............                                     
[6320]..................  Beneficiary method of payment....................                                     
[6400]..................  Beneficiary information..........................                                     
[6410]..................  Beneficiary advice information...................                                     
[6500]..................  FI to FI information (generic) ..................                                     
----------------------------------------------------------------------------------------------------------------
<SUP>aFor purposes of comparison, a description of the current format and required fields is contained in the        
  Computer Interface Protocol Specifications (CIPS) pages 5.8.1, 5.8.2., and 5.8.9.                             
<SUP>bMandatory fields are marked ``required;'' fields that may be omitted are marked ``optional;'' and those fields 
  appended by Fedwire processing are marked ``appended.'' In general, optional tags may be omitted, but         
  sometimes are specifically required by the structured third-party funds transfer format rules. For example, if
  there is information in the originator [5000] field, there must be related information in the originator's    
  financial institution [5100] field. The complete set of structured third-party funds transfer format rules,   
  revised to reflect the new field tags, will be published in CIPS.                                             
<SUP>cThe maximum field size includes the six character field tag.                                                   
<SUP>dThe interface code and fields with tags in the 1000 series are designed to carry technical information. The    
  content and purpose of these tags and fields will be defined more fully in the new CIPS.                      
<SUP>eField will contain 16 characters in an intercept message because format code is omitted.                       

[FR Doc. 94-31980 Filed 12-30-94; 8:45 am]
BILLING CODE 6210-01-P