[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.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.3 Fedline institutions will be
somewhat less affected as the Fedline software enhancements
required to implement the expanded format will be provided by the
Federal Reserve Banks; however, Fedline 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 may need to modify such systems
to support the new format.
\3\Fedline 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 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 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 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 descriptiona Fieldb Sizec
----------------------------------------------------------------------------------------------------------------
Noned................... Interface code................................... Appended................ 1
[1100]d................. Message disposition.............................. Appended................ 9
[1110]d................. Acceptance time stamp............................ Appended................ 18
[[Page 123]]
[1120]d................. OMAD............................................. Appended................ 36
[1130]d................. Error............................................ Appended................ 46
[1140]d................. Special handling instructions.................... Appended................ 33
[1500]d................. Sender supplied information...................... Required................ e18
[1510]d................. Type/Subtype code................................ Required................ 10
[1520]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) ..................
----------------------------------------------------------------------------------------------------------------
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.
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.
cThe maximum field size includes the six character field tag.
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.
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
