The full text on this page is automatically extracted from the file linked above and may contain errors and inconsistencies.
FEDERAL RESERVE BANK
OF NEW YORK
[
Circular No. 10674 "I
December 13, 1993
J
PROPOSAL TO EXPAND TH E FED W IRE FUNDS TR A N SFER FORMAT
Com m ents Invited by M arch 4 , 1 9 9 4
To All Depository Institutions in the Second
Federal Reserve District, and Others Concerned:
Following is the text of a statement issued by the Board of Governors of the Federal Reserve
System:
The Federal Reserve Board has published for public comment a proposal to expand the Fedwire
funds transfer format and adopt a more comprehensive set of data elements. The Board is proposing
implementation of the new format by late 1996.
Comments are requested by March 4, 1994.
An expanded Fedwire funds transfer format would improve efficiency in the payments mechanism
by reducing the need for manual intervention when processing and posting transfers.
In addition, a more comprehensive set of data elements would permit the inclusion of more complete
name and address information for all parties to a transfer, which would be required under regulations
proposed by Treasury.
A copy of the text of the Board’s proposal is being sent to the head office of all depository
institutions in this District, and to those individuals on our mailing lists who have requested circulars
issued by this Bank concerning electronic funds transfer matters; the proposal has also been
published in the Federal Register of December 1, 1993 (58FR 229). A copy of the proposal may
also be obtained at this Bank (33 Liberty Street) from the Issues Division on the first floor, or by
calling our Circulars Division (Tel. No. 212-720-5215 or 5216).
Comments on the proposal should be submitted by March 4 , 1994, and may be sent to the Board
of Governors, as specified in the notice, or at this Bank, to Henry F Wiener, Vice President,
Electronic Payments Function.
W
illiam J.
M
cD o n o u g h ,
President.
FEDERAL RESERVE SYSTEM
Docket R-0817
Federal Reserve Bank Services
AGENCY:
Board of Governors of the Federal Reserve System.
ACTION:
Notice of proposed service enhancement.
SUMMARY:
The Board is requesting comment on a proposal to expand
the Fedwire funds transfer format and adopt a more comprehensive
set of data elements.
The Board is proposing implementation of the
new format by late 1996.
An expanded Fedwire funds transfer format
would improve efficiency in the payments mechanism by reducing the
need for manual intervention when processing and posting transfers.
Further,
truncation
of
payment-related
information
would
be
minimized when forwarding payment orders through Fedwire that were
received
via
other
large-value
transfer
systems,
such as
the
Clearing House Interbank Payments Systems (CHIPS) and Society for
Worldwide Interbank Financial Telecommunication (SWIFT).
A more
comprehensive set of data elements would also permit the inclusion
of more complete name and address information for all parties to a
transfer, which would be required under regulations proposed by
Treasury
requesting
(58
FR
46021,
comment
institutions,
on
Aug.
the
31,
1993).
benefits
to their customers,
and
The
costs
Board
to
is
depository
and to the overall payments
mechanism of expansion of the Fedwire funds transfer format.
[Rerf. C lfi. No . 10674]
also
2
DATES:
Comments must be submitted on or before March 4, 1994.
ADDRESSES:
may
Comments, which should refer to Docket No. R-0817,
be mailed
Governors
of
Constitution
to Mr.
the
William W.
Federal
Avenue,
Wiles,
Reserve
Secretary,
System,
N.W., Washington,
D.C.
20th
Board
Street
20551.
of
and
Comments
addressed to Mr. Wiles may also be delivered to the Board's mail
room between 8:45 a.m. and 5:15 p.m., and to the security control
room outside of those hours.
Both the mail room and the security
control room are accessible from the courtyard entrance on 20th
Street between Constitution Avenue and C Street, N.W.
Comments may
be inspected in room MP-500 between 9:00 a.m. and 5:00 p.m., except
as provided in Section 261.8 of the Board's Rules Regarding the
Availability of Information, 12 CFR 261.8.
FOR FURTHER INFORMATION CONTACT:
Gayle Brett, Manager (202/452-
2934), or Sandra Scales, Financial Services Analyst (202/452-2728),
Division of Reserve Bank Operations and Payment Systems.
hearing impaired only:
For the
Telecommunications Device for the 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's Fedwire funds transfer system and the Clearing
House for Interbank Payments System (CHIPS).
In 1992, the combined
daily average volume of these systems exceeded 420,000 transfers
with a value exceeding $1.7 trillion.
A significant number of the
December 13, 1993
To the Addressee:
The enclosure to this circular has been mailed directly to
the head office address of each depository institution on our
mailing lists. As indicated in the circular, you can pick up a
copy of the enclosure at this Bank (33 Liberty Street) from the
Issues Division on the first floor. If you would like the
enclosure mailed to you, please complete the lower portion of
this letter and mail it back to the Circulars Division/ Federal
Reserve Bank of New York, 33 Liberty Street, New York, N.Y.
10045; your name can also be added to a special mailing list to
receive official circulars pertaining to electronic funds
transfer matters in the future.
Please print:
[ ] Please mail the enclosure to Circular No. 10674
[ ] Please add my name to appropriate mailing list
Name
Title .
Company
Address
City ....................
State .......
ZIP
Circulars Division
FEDERAL RESERVE BANK OF NEW YORK
EFA
3
transfers sent over these payment systems are based on payment
instructions received over a message switching system operated by
the Society for Worldwide Interbank Financial Telecommunication
(SWIFT).
From time to time, the format used to transmit payment
orders on Fedwire has been modified to accommodate industry demands
for the adoption of standards that facilitate end-to-end computer
processing.
structure,
While these changes provide a more consistent data
technical
limitations
at
that
time
prohibited
the
Federal Reserve from significantly expanding the field sizes in
response to industry requests. 1
SWIFT serves 3,000 institutions worldwide and uses a
comprehensive format for the transmission of information between
its members.
This format is designed to facilitate end-to-end
computer processing and provide sufficient space to communicate all
the payment-related information needed by its members to process
the payment instruction.
to
both
Fedwire
and
Payment orders sent on SWIFT map easily
CHIPS;
however,
initial
field
length
limitations on both the CHIPS and Fedwire systems required the
manual truncation of some vital payment information.
^■The structured Fedwire format was announced in 1986 when most
Fedwire participants used the BOPEAP telecommunications protocol to
connect to the Federal Reserve.
BOPEAP inherently limited the
number of characters a message could contain.
The final BOPEAP
link was converted to the more advanced FRISC and FLASH
telecommunications protocols in 1991.
4
In 1992, CHIPS adopted a new format that incorporated
certain aspects
of the
SWIFT
format to decrease
the
need to
truncate payment-related information and significantly improve the
ability of receiving institutions to process payments for their
customers.
As a result, payment instructions sent over SWIFT can
be processed
efficiently on CHIPS without manually truncating
information that the receiver may need to identify and process the
payment.
In November 1992, the American Bankers Association (ABA)
Funds Transfer Task Force, under the auspices of the ABA Wholesale
Operations Committee (the Committee), recommended that the Federal
Reserve
adopt
a more
comprehensive
set
of
data
elements
for
wholesale electronic funds transfers, and forwarded to the Federal
Reserve
a proposal
for
a new Fedwire
format.
The
Committee
recognized that adoption of a new format would not be a simple
undertaking,
efficiency
Further,
but
and
stated
it to
productivity
of
be
essential
the
U.S.
to
the
payments
the Committee recognized that a revised,
long-term
mechanism.
"CHIPS-like"
Fedwire format would enhance compatibility with the SWIFT and CHIPS
formats.
Federal
Reserve
staff
conducted
a
detailed
business
analysis of the format proposed by the ABA and evaluated requests
to modify the existing format from the Departments of Justice and
Treasury.
The results of that analysis indicate that the proposed
format would more fully accommodate the business needs of the
banking community as well
as the requests
of
law enforcement
5
agencies for more complete information about the parties to a funds
transfer.
Further, the proposed format is not expected to cause
any degradation in service, and its incorporation into the Fedwire
funds transfer service seems justified.
The Board proposes to adopt a new format for the Federal
Reserve's Fedwire funds transfer service,
recognizing that the
payments system would be more efficient if all large-value transfer
services used a common format structure that accommodates industry
and law enforcement demands for increased information in messages.
The proposed format is substantially similar to the CHIPS-like
format
proposed
accommodate
by
the ABA,
certain
but with minor
Fedwire
business
modifications
and
to
technical
specif ications.
The Board proposes to implement the expanded format by
late 1996.
The adoption of the format will require extensive
automation 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 Federal
Reserve recognizes that many large depository institutions today
use vendor-provided or in-house developed software to participate
in CHIPS and SWIFT.
Because these institutions are familiar with
formats similar to the one proposed 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.
6
The Federal Reserve provides software to approximately
7,500
depository
Fedline®.2
institutions
that
access
Fedwire
through
Fedline® institutions would be somewhat less affected
as the Fedline® software enhancements required to implement the
proposed format would be provided by the Federal Reserve Banks.
Fedline®
participants
training
to
become
will
require
familiar
with
substantial
the
new
education
format.
and
Those
institutions with back-office systems that interface Fedline® may
need to modify such systems to support the new format.
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,
Aug.
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 individuals involved in such illegal
activities.
Although there
Fedwire
format to
is
include
insufficient
space
in the current
complete originator and beneficiary
information, the Board encourages Fedwire users to use available
2Fedline® is the Federal Reserve's proprietary software
package for personal computers that is used by low-to-medium volume
Fedwire participants to electronically access Federal Reserve
services.
7
optional format fields to include such information.
For example,
in a third-party transfer, the originator (ORG=) and beneficiary
(BNF=) fields must contain data in order to be accepted by Fedwire.
While these fields can accommodate the originator and beneficiary
name and account number, there is generally insufficient space for
address information.
If optional fields, such as the "Originator
to Beneficiary Information" (OBI=) or "Bank to Bank Information"
(BBI=) fields, are not used for payment-related information, these
fields
could be used to
specific
optional
field
convey
is
the
address
recommended
for
information.
including
No
address
information as different optional fields may be available for use
in any given wire transfer.
The Board recognizes that these recommendations may not
assist depository institutions in complying with the travel rule in
all cases.
Ideally,
the Fedwire funds transfer format should
provide sufficient space to accommodate the information desired for
law enforcement purposes.
In addition to increasing the space
available for transfer party information,
the proposed Fedwire
format is much more structured and specific about where information
is carried in the message.
A
detailed
description
of
the
proposed
format
and
examples of usage for business and law enforcement purposes are
included following the description of the proposed alternative
implementation plans.
A complete list of field tags and a glossary
of terms and field tag definitions are attached to this notice.
A
detailed technical description of the proposed format that includes
8
a comparison to the current format, as well as a summary of format
differences, will be made available upon request from the local
Federal
Reserve
Bank
to
persons
with
a
need
to
know
the
specifications that are willing to sign a confidentiality agreement
to protect the integrity of the Fedwire system.
This information
may be useful for computer interface banks and vendors as they
analyze the effects of the format.
Description of Alternative Implementation Plhns
The Board proposes that the Federal Reserve Banks will
fully implement the expanded format by late 1996.
This should
allow sufficient time for the Federal Reserve to make necessary
changes to both the Fedwire funds system and Fedline® software, and
for the industry to incorporate and fully test the software changes
that must be made to the funds transfer, communications, customer
delivery, and back-office processing systems used by depository
institutions that connect to Fedwire.
The Federal Reserve System is currently in a period of
transition, migrating from twelve separate payment processing sites
into one consolidated automation site.
This consolidation involves
significant software, hardware, network, and computer operations
changes; the related application and operating system software will
be in a state of transition until 1995.
The adoption of the
9
proposed format requires revision of many programs and databases
that comprise the core of the Fedwire funds transfer system.
The
Fedwire funds transfer software that will be used in the automation
consolidation environment will be implemented by all Reserve Banks
by early 1995.
Assuming that a final format is adopted in mid-
1994, the Federal Reserve System would expect to complete software
development efforts and internal testing of the revised Fedwire
software in late 1995, at which time the depository institution
testing phase could begin.
An update of the computer interface
protocol specifications (CIPS) document, which details software and
technical requirements, and installation and certification testing
guidelines would be published six months prior to the time software
would be made available for testing.
The
testing
phase
for
computer
interface
depository
institutions would encompass two steps: software certification and
implementation testing.
the
Federal
institutions.
Reserve
Fedline® software would be certified by
prior
Vendors
and
to
its
distribution
depository
to
institutions
depository
that
have
developed in-house computer interface funds transfer systems would
be required to certify their software by demonstrating that their
software will accommodate the new 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 they can meet all of
the CIPS requirements.
10
Three different implementation cutover strategies are
discussed below.
The Board welcomes comments as to the viability
of each plan and anticipated effects on and benefits for depository
institutions.
nationwide
The alternatives under consideration include: (1) a
same-day
cutover,
(2)
a
"receive-first"
phased
conversion, and (3) an "institution-by-institutionM full function
conversion.
Alternative one —
day.
All participants cut over on the same
Under this strategy, transition from the current format to
the expanded format would be accomplished over a three-day, bank
holiday weekend when both the financial markets and the Federal
Reserve are closed.
Such a plan requires substantial coordination
and testing between the depository institutions and the Federal
Reserve Banks.
It is anticipated that a same-day transition period
would significantly reduce participants' costs because the need to
support two formats simultaneously is removed.
This plan allows
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.
Under a same-day cutover, the Federal Reserve recognizes
there could be a substantial disruption to the payments system if
one or more large participant(s) were unable to process under the
new format or experienced some other implementation-related problem
that caused
service.
a prolonged outage
of the Fedwire
funds transfer
Complete and comprehensive testing on the part of every
11
on-line institution, both internally and with the Federal Reserve
is required for a conversion of this magnitude to be successful.
A
long
lead
time
is
necessary
to
ensure
that
software
is
thoughtfully designed and fully tested by both the Federal Reserve
and on-line participants.
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
environment for the first time on the same date.
production
Due to the
magnitude of the software changes and the large population of
participants, in excess of 11,000 depository institutions, it would
not be feasible to fall back to the previous software if problems
during
cutover
coordinate
software
the
and
were
encountered.
timely
de-installation
related procedural
institutions.
It would
and
changes
be
impossible
to
re-installation
of
for more
than
11,000
Instead, the affected participants would have to
quickly repair,
test,
and recover their new software.
In the
interim, the payments system could be severely hampered for one or
more
days.
associated
Although
with
this
there
is
a
significant
implementation
plan,
amount
a
of
risk
successful
implementation would allow all participants simultaneously to take
advantage of the increased efficiency and effectiveness afforded by
the new format.
Alternative two —
A two-stage implementation, with each
stage lasting four to six months.
Under this plan, participants
would begin receiving the new format before they would begin
12
sending the new format.
Messages sent in the current format would
be converted to the new format by Fedwire, then delivered.
Phase one, a transition period during which participants
convert from receiving the current format to receiving the new
format, would commence during the late 1995 to early 1996 time
frame.
In this phase,
Fedwire software would accept only the
current format but would deliver 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 current format.
Once the receiver is able to
receive the new format, Fedwire 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 current
format to the equivalent fields in the new format.
As the field
lengths in the new format are equal to or larger than the current
format, all transfer information would be carried forward without
truncating any data.
The "new format" message will contain only
the fields necessary to carry forward all the information in the
"old format" message.
The converted message would be somewhat
longer than the original message because information commingled in
the third-party section of the current format would be allocated to
specific fields 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 the new format.
Phase two, a transition period during which participants
convert from sending the current format to sending the new format,
13
would commence in mid-1996.
In this phase, Fedwire software would
continue to accept the current format, but would also accept the
new format.
All messages would continue to be delivered to the
receiver in the new format.
Until a sender begins sending the new
format, Fedwire will continue to accept the sender's messages and
convert them to the new format for delivery to the receiver.
Phase
two would end in late 1996, at which time all participants would
have the ability to both send and receive the new format.
The
current format would no longer be supported.
The receive-first alternative limits the risk that the
overall payments system would experience a major disruption on a
particular day as very few banks would go through the transition on
any given day.
Separating the conversion along functional lines
also helps minimize the risk to the payment system.
that experiences
severe
A participant
implementation-related problems on its
receiving cutover date would still be able to inquire against
balances and originate transfers, thus retaining access to funds
that had been credited to its account.
If the bank's receiving
problems were not readily resolved, the bank would have the option
of reverting to the previous software or moving to a back-up
system.
A participant that experiences problems on its sending
cutover date would still be able to receive transfers and thus
monitor its account balance.
If the bank's sending problems are
not readily resolved, the bank has the option of reverting to the
previous software or moving to a back-up system.
14
Alternative three —
Each bank selects a date over the
course of twelve months on which to convert both its send and
receive functions to accommodate the new format.
period would begin in late 1995.
The transition
Under this plan, Fedwire would
accept messages in either format and map between formats.
All
participants would be required to complete conversion to the new
format within the twelve-month transition period, after which time
the current format would no longer be supported.
Under
conversion,
the
institution-by-institution
participants would
staggered schedule.
implement
the
full
new
function
format
on
a
As a result, a participant may send a message
in a format that the receiver cannot process.
In this case,
Fedwire will convert the message to a format that the receiver can
process.
For example, if the receiver were able to accept the new
format, then messages originated in the old format would be mapped
into the new format.
Fedwire would convert the field tags and
identifier codes to the equivalent fields in the new format.
If
the receiver was still processing the current format, then messages
received in the new format would be reduced to the current format;
however, critical payment related information may be truncated.
That is, if the sending bank included more information in a field
than the equivalent field in the current Fedwire format could
accept,
the extra characters would be omitted from the message
delivered to the receiver.
Truncation would be necessary 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,
15
data truncation could be very extensive.
When mapping from the new
format to the old format, Fedwire would establish a set of interim
field
length
guidelines
for
truncating
data.
Fedwire
would
automatically apply these guidelines when mapping messages from the
new format to the current format.
If a sender included more text
than allowed by the guidelines, the excess characters in each field
would be truncated.
Adoption of this alternative would reduce the likelihood
of a major payment system disruption because very few banks will go
through the transition on any given day; however, business risk may
be
increased.
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.
In the interim, 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 which intended receiver 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 Mold
format” participants.
Because messages sent in the new format may
exceed the interim field length guidelines and critical payment
information may be lost in the truncation process, there would be
an increased business risk for all receivers that use the old
format.
The receiver that converts late in the process has an
increased risk of misapplying payments and incurring posting delays
because most of the wires it receives would have been originated
16
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.
There also may be more risk to the individual participant
because both the send and receive functions convert on the same
date.
It is conceivable that a participant experiencing severe
implementation-related
experience
problems
a complete
on
its
cutover
date
could
loss of function because both send and
receive functions are in a state of transition at the same time.
Thus, all the institution's normal capacity to monitor and adjust
its account may be disrupted,
including the ability to inquire
against balances, originate transfers,
and receive notification
that funds had been credited to its account.
In that case, a bank
may be compelled to revert to previous software or back-up systems
at an earlier point than if some degree of monitoring capability
were retained.
Description of the Proposed Fedwire Format
The proposed 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 SWIFT formats and
provides an expanded message length and variable-length fields.
The proposed
different
format
when
is modeled
necessary
to
on the
CHIPS
accommodate
format
technical
and
only
processing
requirements specific to Fedwire or to delete technical processing
17
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, including the originator, originator's bank,
beneficiary,
beneficiary's
bank,
intermediary
bank3
and
instructing bank.
The proposed 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
has
significantly increased; and field tags (codes that identify the
type of information a field may carry)
alpha.
are numeric rather than
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 fully and
consistently translate payment order information
into discrete
3The 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 in all cases.
18
fields, which will permit Fedwire participants to automate more
fully payment order processing.
The presentation of routing and transfer information in
the proposed format has been reorganized to follow more closely the
path of a message, that is, from sender to receiver.
The proposed
format presents the sending bank routing number and sending bank
name before the receiving bank routing number and receiving bank
name.
The
proposed
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,
fields.
originating bank,
and instructing bank information
The proposed format's presentation of routing and transfer
party information is consistent with the presentation of similar
data in the CHIPS and SWIFT formats.
Consistency among these
formats should facilitate investigation and resolution when errors
occur.
The proposed format can accommodate much longer messages
than the current Fedwire format.
For example, outgoing messages,
those originated by a depository institution and received into
Fedwire, may contain a maximum of 1731 characters, as compared to
a maximum of 604 characters under the current Fedwire format.
Intercepts, messages returned to the sending depository institution
by Fedwire, may contain a maximum of 1834 characters, as compared
to 731 characters today.
Fedwire
to
a receiving
Incoming messages, those delivered by
depository
institution,
may
contain
a
19
maximum of 1808 characters in the proposed format, as compared to
723 characters today.
Message length varies due to the information
appended during processing by the Federal Reserve.
Field size has been increased and the field structure has
changed under the proposal.
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 specifically 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 numbers.
the field.
Each element has a designated position within
Valid elements are defined for each field tag.
For
example, the originator field has a "field tag" of [5000] that
would be followed by the "elements," such as account number, name
and address.
The
number
of
field
tags
is
greatly
expanded
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 proposed
format.
For example,
the
beneficiary
format,
information
is tag
field
denoted by BNF=
in the current
proposed format.
(Appendix A lists the complete set of field tags
and the Glossary provides field tag definitions.)
[4200]
tag,
in the
Additional field
tags have been defined to denote each of the standard fields in a
20
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 proposed format.
Elements, the information that follows a field tag,
be presented in a specific order within a field.
must
The information
may be either freeform and of variable length, such as address, or
may require a specific format, such as the dollar amount.
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 (*) will always follow a variable length element to denote
the end of the element.
element.
No delimiter will follow a fixed length
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.
current
format allows the
identifier code,
For example,
in this case
the
/AC-
account number, to be used somewhere in the field following the
beneficiary field tag, BNF=.../AC-123. Under the proposed format,
the beneficiary field tag [4200] may be followed by up to five
elements: a defined 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
21
of number that follows it, in this case "D" represents account
number.
The other identifier codes are outlined in the Glossary.
The proposed format would also provide ample space to
include identifying information in a payment order to facilitate
financial institution compliance with Treasury's proposed travel
rule.
For example, the field following the originator tag [5000]
has sufficient space, up to a maximum of .186 characters (including
the tag) for the originator's financial institution to include the
originator's account number,
name,
and address.
The proposed
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.
If the customer of the originating bank is a nonbank
financial institution, the originator tag [5000] and originator's
financial
institution tag
transmittor
respectively.4
and
[5100]
can be used to
transmitter's
financial
identify the
institution,
In this case, the field following the originator
tag [5000] can be used to reflect the transmitter's account number,
name and address.
financial
Information
identifying the
institution,” the nonbank financial
"transmitter's
institution that
4The
terms
"transmittal
order,”
"transmitter”
and
"transmitter's financial institution" are defined in the notice of
proposed rule-making (58 FR 46014, Aug. 31, 1993).
22
accepts the payment order from the transmitter, can be included in
the field following the originator's financial institution tag
[5100].
If the bank accepting the transmittal order from the
transmitter's financial institution (the originating bank) is also
the institution sending the payment order to Fedwire, then it can
be
identified by routing number and short name
in the
field
following the Sender DFI tag [3100].
For example, John Doe is sending $7,000 to his aunt,
Sally Jones, who has an account at Bank Seven.
His aunt requests
that he include instructions for her bank to call her when the
money is received.
John decides to send the money from his money
market mutual fund at Big Broker/Dealer.
John asks his account
officer at Big Broker/Dealer 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 his aunt's name and address,
but
is
unaware of her account number.
Big
Broker/Dealer
prepares
a
transmittal
order
and
forwards to its bank, Bank Away for transmission over Fedwire:
Amount:
$7,000
Date:
July 12, 1993
From:
Our Account 767676, on behalf of our customer
John
Doe,
account
MMMF123456,
Avenue, Watertown, Md;
One
Wayward
2 3
To:
Bank
Seven,
Chicago,
ABA
079999999,
further credit to Sally Jones,
for
1920 Flapper
Lane, Chicago, II;
Instructions:
Phone advice —
Ms. Jones (312)555-1212
Bank Away accepts Big Broker/Dealer's transmittal order
and prepares a corresponding transmittal order to send over Fedwire
(in bold):
Description
TAG
ELEMENTS
Type/Sub-type
[1510]
1000
IMAD
[1520]
0712E9999999000001
Amount
[2000]
$7,000.00
Sender DFI
[3100]
059999999AWAY*
Sender Reference
[3320]
9999999999999999
Receiver DFI
[3400]
079999999BANKSEVEN*
Business Function Code
[3500]
CTR
Beneficiary's FI
[4100]
F079999999*BANK SEVEN NA*
Beneficiary
[4200]
DUNKNOWN*SALLY JONES*
1920 FLAPPER LA*
CHICAGO, IL*
Originator
[5000]
NMMMF123456*JOHN DOE*
1 WAYWARD AVE*
WATERTOWN, MD*
Originator's FI
[5100]
D7 67 67 6*BIGBROKER/DEALER*
222 CAMDEN YARDS CIRCLE*
BALTIMORE, MD*
24
FI to FI
Beneficiary's
FI Advice
[6310]
PHN ON RECEIPT *
CALL MS JONES 312-555-1212*
If the transmitter'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].
In the example above, if Bank Away is not a Fedwire participant but
is a respondent of Ultimate Bank & Trust,
which
is a Fedwire
participant, then the payment order sent to Fedwire would change as
follows:
Description
TAG
ELEMENTS
Sender DFI
[3100]
058888888ULTIMATE*
Instructing FI
[5200]
F059999999*BANK AWAY*
If the customer of the originating bank is an individual,
corporation, or bank, the originator tag [5000] and originator's
financial
institution tag
[5100]
can be used to
identify the
originator and originator's financial institution, respectively.5
In the example above, if John Doe decides to send the money from
his account (12331234) at Bank Away, then the payment order sent to
Fedwire would change as follows:
5The terms "originator,” "originator's financial institution,”
and "payment order” are defined in the notice of proposed rulemaking (58 FR 46014, Aug. 31, 1993).
25
Description
TAG
ELEMENTS
Sender DFI
[3100]
059999999AWAY*
Originator
[5000]
D12331234*JOHNDOE*
1 WAYWARD AVE*
WATERTOWN/ MD*
[5100]
Originator's FI
If the beneficiary's
F059999999*BANK AWAY*
financial
institution
is not a
Fedwire participant, the sender may direct the payment order to a
correspondent 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 FI tag [4100].
The correspondent would be identified in the field following the
receiver DFI tag [3400],
In the example above, if Sally Jones is
not a customer of Bank Seven, but her
credit union, Local CU, is its respondent, then the payment order
sent to Fedwire would change as follows:
Description
TAG
ELEMENTS
Receiver DFI
[3400]
079999999BANKSEVEN*
Beneficiary's FI
[4100]
F271011111LOCAL CU*
808 WATERTOWER CENTER*
CHICAGO, IL 60604*
26
Beneficiary
[4200]
DUNKNOWM*SALLY JONES*
1920 FLAPPER LA*
CHICAGO, IL*
The beneficiary tag [4200] and beneficiary's financial
institution tag [4100] can also 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 non-bank financial
institution.6
In this case, the field following the beneficiary
tag [4200] can be used to reflect the recipient's account number,
name and address.
financial
Information identifying the "recipient's
institution,” the nonbank financial
institution that
accepts the payment order for the recipient, can be included in the
field following the beneficiary's financial institution tag [4100].
If the
bank
accepting
the payment
order
for delivery to
the
recipient's financial institution is also the institution that is
receiving the payment order from Fedwire, then it can be identified
by routing
number
and
short
name
in the
field
following the
Receiver DFI tag [3400].
In the example above, if John Doe had sent the money to
his aunt in care of a currency exchanger, Money Swap, who is also
6The terms "recipient" and "recipient's financial institution"
are defined in the notice of proposed rule-making (58 FR 46014,
Aug. 31, 1993) and include, respectively, the terms "beneficiary"
and "beneficiary's bank."
For the purposes of Fedwire, the terms
"recipient" and "recipient's financial institution" will refer to
transactions in which a nonbank financial institution makes payment
to the person named in the transmittal/payment order.
27
a customer of Bank Seven, then the payment order sent to Fedwire
would reflect the following:
TAG
ELEMENTS
Receiver DFI
[3400]
079999999BANKSEVEN*
Beneficiary's FI
[4100]
D6 66666 *MONEY SWAP INC*
Description
10363 INTERNATIONAL BLVD*
CHICAGO, IL 60604*
Beneficiary
[4200]
DUNKNOWN*SALLY JONES*
1920 FLAPPER LA*
CHICAGO, IL*
The
proposed
format
also
accommodates
inclusion
of
complete information received in an international (SWIFT or CHIPS)
transmittal of funds that must be forwarded over Fedwire.
For example, on July 12, 1993, First Bronx NY receives a
SWIFT message from Black Forest Bank, Munich
(SWIFT identifier
BBFBKDEZZ) to pay Cowboy Trust, Dallas for further credit to T.
Edwards, account 123456 at the Rodeo Road Branch in Austin.
The
SWIFT 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.
transfer amount —
Do not deduct any related fees from the
charge fee separately.” First Bronx prepares a
28
corresponding transmittal order and forwards it over Fedwire (in
bold):
£AG
ELEMENTS
Type/Sub-type
[1510]
1000
IMAD
[1520]
0712B9999999000001
Amount
[2000]
$34,000.00
Sender DFI
[3100]
029999999FIRST BRONX NY*
Sender Reference
[3320]
9999999999999999
Receiver DFI
[3400]
119999999COWBOYBANK*
Business Function
Code
[3500]
CTR
Intermediary FI
[4000]
F029999999FIRST BRONX NY*
Beneficiary's FI
[4100]
FI19999999*COWBOYBANK*
Description
RODEO ROAD BRANCH*
AUSTIN*
Beneficiary
[4200]
D123456*T. EDWARD*
Originator
[5000]
DUNKNOWN*FRANZ MOUSSE*
DBA
STEAK
PALACE*
MAXIMILLIANSTRASSE 38*
MUNICH, GERMANY*
Originator's FI
[5100]
BBFBKDEZ Z*BLACKFOREST BK*
MUNICH, GERMANY*
29
Originator to
Beneficiary
Information
[6000]
PAY T. EDWARDS $34,000 US,*
$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
Receive FI
Information
If
a
[6100]
PER BLACK FOREST BANK*
PAY IMMEDIATELY. DO NOT DEDUCT ANY*
RELATED FEES FROM THE TRANSFER*
AMOUNT — CHARGE FEE SEPARATELY*
transmittal
order
is
received
by
a
domestic
financial institution via CHIPS, when a corresponding payment order
is prepared on Fedwire, the sending bank's CHIPS identifier may be
included in the appropriate field.
If the CHIPS participant is the
originator's financial institution,
tag
[5100],
then the CHIPS
identifier may be substituted for the SWIFT identifier in that
field.
the
If the CHIPS participant is not the originator's bank, then
originator's
bank's
SWIFT
identifier
remains
in
the
originator's FI tag [ 5 1 0 0 ] and the CHIPS participant's identifier
is shown in the instructing financial institution tag [ 5 2 0 0 ] .
In
the example above, if Black Forest Bank has a New York branch that
is a CHIPS participant:
Description
TAG
ELEMENTS
Originator's FI
[5100]
BBFBKDEZZ*BLACKFOREST BK*
Instructing FI
[52 00]
CBLKFOR99*BLACKFOREST NY*
Competitive Impact —
The Board believes that this proposal
3 0
will have no
providers
to
adverse
compete
effect
on the
ability
effectively with
providing similar services.
the
of
other
Federal
service
Reserve
in
Specifically, the Board believes that
implementing the proposed 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,
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 proposed
format will increase compatibility among CHIPS, SWIFT 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 services.
Enhanced compatibility also broadens the range of choices that
sending and intermediary financial institutions have when selecting
a transfer system.
Request for Comment
The Board requests comment on its proposal to adopt an
expanded Fedwire format and adopt a more comprehensive set of data
elements by late 1996 and on the benefits and costs to the industry
of converting to the expanded format.
requests comments on the following:
I.
General
Specifically,
the Board
31
A.
Do you believe the proposed format will be flexible
enough to meet your existing and future business needs?
Law enforcement's needs?
Will it facilitate compliance
to Treasury's proposed travel rule?
II.
Specific Effects on Depository Institutions
A.
Type
of
Connection
—
Please
describe
how
your
institution accesses Fedwire and the modifications you
anticipate making to that facility to support an expanded
format:
1.
Do you access Fedwire through a computer interface,
Fedline®, or the off-line service?
2.
If you have a computer interface,
is it a vendor
supplied or in-house developed system?
How long
does the development team or vendor estimate that
it will take to develop,
test and implement the
necessary software modifications to accommodate the
proposed format at your site?
charges
assessed
for
Are there additional
changes
required
by
the
Federal Reserve System?
3.
Does your institution also use CHIPS?
If yes,
do you
use
a different
funds
transfer
system to access CHIPS or does the system you use
to access Fedwire also support CHIPS?
If
yes,
will
conversion
to
the
new
format
be
simplified because you already have software that
3 2
processes CHIPS transfers?
4.
If the system is vendor supplied, does the vendor
currently support CHIPS and SWIFT interfaces?
5.
Will
back
room
systems
that
upload
files
or
download files to your funds transfer system (or
Fedline®) have to be modified as a result of the
format
change?
To
what
degree:
significantly,
moderately, or not at all?
What types of back office systems: general ledger,
deposit accounting, customer information, customer
delivery, or something else?
6.
Will it cost you significantly more to process a
larger format?
B.
If yes, in what ways?
Operations
1.
What types of procedural changes do you anticipate
to accommodate the new format?
2.
What
internal
training
and
customer
education
efforts do you believe to be required?
3.
What other operational effects and costs do you
anticipate?
C.
Customer Effects
1.
Do you expect your customers to incur additional
costs to accommodate the new format?
type of costs?
If yes, what
3 3
2.
Do you expect the new format to have a minor or
significant impact on your customers?
Why?
III. Implementation Strategies
A.
Schedule
1.
Is the proposal to implement the new format by late
1996 reasonable?
If not, when do you believe your
institution and the industry in general could be
ready for a new format?
2.
Do you believe the schedule can accommodate your
institution's testing requirements?
What are your
institutions testing requirements?
B.
Implementation Alternatives
1.
Will any one alternative be more problematic than
another for your institution?
Is any alternative
likely to be more beneficial than another?
describe
the
advantages
and
Please
disadvantages
you
anticipate under each alternative:
a.
One-day
cutover:
all
participants
begin
sending and receiving the new format on the
same date.
b.
Two-stage
cutover:
participants
will
begin
receiving the new format during phase one and
sending the new format during phase two.
phase will last six months.
Each
34
c.
staggered-date
full
function
cutover:
each
participant selects a date to begin sending
and receiving the new format.
By order of the Board of Governors of the Federal Reserve
System.
(signed) William W. Wiles
William W. Wiles
Secretary
35
GLOSSARY
ACCEPTANCE TIMESTAMP
TAG [1110]
ADJUSTMENT TAG [3000]
Field indicatesthe date and time that Fedwire
accepted the transfer. Also includes the
Fedwire application ID.
Field used tocarrythe as-ofdate and reason
foran adjustment; supplied by the FRB
grantingthe adjustment.
ADVICE CODE
An element ofthe FI to FI advice tags (see FI
to FI); a three character code that identifies
the method tobe used to notifya party of
receiptoffunds:
LTR Letter
PHN Phone
TLX Telex
WRE Wire
AMPLIFYING ADVICE
An element ofthe FI to FI advice tags (see FI
to FI); descriptive information used to deliver
the payment notification, e.g.phone number
and contact name.
ALPHA
EBCDIC data representation standard;
includes any alphabetic character A-Z, space
character, numeric digit0-9,and the
following: .< >() + !& $;/!,%-?’:
# @ = "{ } \
AMOUNT TAG [2000]
Field used toindicate the amount tobe
transferred; eighteen characters, with commas,
period, and dollar (dollarsign isoptional).
36
BBI=
Field tagused toidentifyBank toBank
Information inthe current format; contains
miscellaneous information pertaining tothe
transfer.
BBK=
Field tagused to identifyBeneficiary’sBank
inthe currentformat; identifiesthe bank
actingasfinancialagent forthe beneficiaryof
the transfer.
BENEFICIARY7
The person tobe paid by the beneficiary’s
bank. Also see RECIPIENT.
BENEFICIARY’S BANK1
The bank identified ina payment order in
which an account ofthe beneficiary istobe
credited pursuant tothe order orwhich
otherwise istomake payment tothe
beneficiary ifthe order does not provide for
payment toan account. Also see
RECIPIENTS FINANCIAL INSTITUTION
BENEFICIARY TAG [4200]
Field used to identifythe person tobe paid by
the beneficiary’sbank or recipient’sfinancial
institution(non-bank).
BENEFICIARY’S FINANCIAL Field used to identifythe beneficiary’sbank or
INSTITUTION TAG [4100]
recipient’sfinancial institution(non-bank) in
which an account ofthe beneficiary/recipient
istobe credited pursuant tothe order or
which otherwise isto make payment.
7Regulatory definition 58 FR 46014, August 31, 1993.
All
similar definitions throughout this document will be identified
with this footnote number.
37
BNF=
Field tagused toidentifythe Beneficiary in
the currentformat; the person tobe paid by
the beneficiary’sbank.
BUSINESS FUNCTION TAG
[3600]
Field used tocarrythe three character code,
formerly known as "Product Code," that
enables the receiverofthe message to
determine the purpose ofthe transfer:
BTR Bank Transfer -Beneficiary iss
bank.
CTR Customer Transfer (Beneficiary isa nonbank)
CKS Check Sa^ie-Day Settlement
DEP Deposit to Sender’sAccount
DRW Drawdown
FFR Fed Funds Returned
FFS Fed Funds Sold
CHIPS
Clearing House Interbank Payments System
CIPS
Federal Reserve Computer Interface Protocol
Specifications
DLM
Delimiter - a code used to mark the end of
variable length data; an asterisk isused as
a delimiter element inthe proposed format.
ELEMENT
A specificpiece ofinformation carried ina
field. Elements further identifyor define the
contents ofa field,forexample, the
beneficiaryfieldgenerally includes elements
such as name and address.
38
ERROR FIELD TAG [1130]
Field iscompleted when the Federal Reserve
returns a Fedwire message tothe sender and
includes an error code, number, and
description, e.g."E185 INVALID
TYPE/SUBTYPE."
FI TO FI TAGS [6100] to
[6500]
Financial InstitutiontoFinancial Institution
Information - General transfer-related and
advice information thatisforwarded from one
financialinstitutiontoanother. In the
proposed format, the FI toFI tagsinclude
information that commonly follows the BBI=
tagand the advice method components ofthe
IBK=, BBKf and BNF= tagsinthe current
format. The FI to FI tagsare:
Receiving FI Information
[6100]
Intermediary FI Information
Intermediary FI Advice Info.
[6200]
[6210]
Beneficiary’sFI Information
[6300]
Beneficiary’sFI Advice Info. [6310]
Beneficiary Method ofPayment [6320]
Beneficiary Information
[6400]
BeneficiaryAdvice Information [6410]
FI to FI information (generic) [6500]
39
FIELD
FUNDS TRANSFER1
A sub-portion ofa message extending from a
tagup to,but not including, another tagor
the end ofthe message. A fieldbegins with a
tagfollowed by one or more individual data
items, calledelements. The definitionofthe
tagwilldetermine the format ofthe fieldand
the elements within the field. For example,
tag [4200] isdefined as "beneficiary"and
contains severalelements thatmay be used to
describe the beneficiary, that is,account
number, name and address,while tag [2000],
which isdefined as amount, contains only one
18-characterelement toidentifythe dollar
amount. See ELEMENT.
The seriesoftransactions,beginning with the
originator’spayment order, made forthe
purpose ofmaking payment tothe beneficiary
ofthe order. The term includes any payment
order issuedby the originator’sbank or an
intermediarybank intended tocarryout the
originator’spayment order. A funds transfer
iscompleted by acceptance by the
beneficiary’sbank ofa payment order forthe
benefit ofthe beneficiaryofthe originator’s
payment order. Automated clearinghouse
transfersor funds transfersgoverned inany
partby the Electronic Funds Transfer Act of
1978 (TitleXX, Public Law 95-630, 92 Stat.
3728, 15 U.S.C. 1693 si seq..as amended from
time to time), are excluded from this
definition.
40
IBK=
Field tagused toidentifyan Intermediary
Bank inthe currentformat; the institution(s)
between the receivinginstitutionand the
beneficiary’sinstitutionthrough which the
transfermust pass,ifspecifiedby the sending
institution. In such cases,thisisthe receiving
institution’screditparty.
IDENTIFIER CODE
The firstelement following a transferparty
tag;a one charactercode thatfurtherdefines
the type ofidentifierthatfollows it(See
IDENTIFIER). Valid codes are:
N=Non-Bank
D=Account Number (DDA)
B=Bank IdentifierCode (BIC/SWIFT)
C=CHIPS Participant
F=Routing Number
A variable-length element that carries a
number or a combination oflettersand
numbers tomore fullyidentifya particular
party ina payment message, forexample, an
account number or routing number. An
identifierfollows each party tag:
Intermediary FI
[4000]
Beneficiary’sFI
[4100]
Beneficiary
[4200]
Originator
[5000]
Originator’sFI
[5100]
InstructingFI
[5200]
A payment order sent from the Fedwire
applicationtothe participatingdepository
institution,the receiver,which notifiesthe
receiverthatfunds have been credited to its
account. An incoming funds transfer is
received when a corresponding Outgoing
Funds Transfer has been initiatedby another
institution. See OUTGOING FUNDS
TRANSFER.
IDENTIFIER
INCOMING FUNDS
TRANSFER
41
IMAD TAG [1520]
Field used tocarrythe Input Message
Accountability Data. IMAD isestablished at
the time the message isfirstreceived by a
Federal Reserve Bank; includes a date, the
logicalterminal (Lterm) associatedwith the
interfacingapplication thatsent the message
toFedwire, and the sequence number
assigned by the interfacingapplication.
INS=
Field tagused toidentifythe InstructingBank
inthe current format; the institutionother
than the originator’sbank that instructsthe
sender toexecute the transaction.
INTERMEDIARY BANK1
A receivingbank other than the originator’s
bank or the beneficiary’sbank.
INTERMEDIARY
FINANCIAL INSTITUTION1
A receivingfinancial institution,other than a
bank, the transmitter’sfinancial institutionor
the recipient’sfinancial institution.
INTERMEDIARY
FINANCIAL INSTITUTION
TAG [4000]
Field used toidentifyan intermediary bank
(see IBK=) or a non-bank financial
institution,other than the beneficiary’sbank /
recipient’sfinancial institution,thatreceives a
payment order from Fedwire or from a
Fedwire participant.
Field used toidentifyan instructingbank or
non-bank financial institution.See INS=.
INSTRUCTING FINANCIAL
INSTITUTION TAG [5200]
INTERCEPT
Fedwire’sresponse tothe sender ofan
outgoing funds transferthatisrejected or
otherwise intercepted. The intercept message
isa copy ofthe outgoing funds transfer
message with a description ofthe error added.
See ERROR FIELD TAG [1130].
42
INTERFACE CODE (No Tag) Field indicatesthe type ofcommunications
protocol used by the application sending an
outgoing funds transfertoFedwire:
X
FLASH
Z
FRISC
43
MESSAGE DISPOSITION
TAG [1100]
A fieldused tocarrycertainmessage-related
control information; the fieldhas four
elements: formatversion, test/production
code, message duplication code (out),and
message statusindicator. Each element is
described below.
Format Version: a two character code used to
identifythe format ofthe message. Generally,
only one valuewillbe valid forthiscode, but
a second value may be defined during a
period oftransitionfrom one format to
another.
Test/Production Code: a one character code
used toindicatewhether the sending
applicationwas inthe testor production
mode when the transferwas originated:
T Test Mode
P Production Mode
Message Duplication Code: a one character
code used toindicatewhether the message
has been sent before:
"" Original Message
P Possible Duplicate
R Retrieval on an Original Message
C Copy ofan Original
Message Status Indicator: One character
code that indicatesthe processing status ofthe
message:
0 Intercepted Outgoing Transfer
2 Accepted (processed) Outgoing
Transfer resultingina debit/credit
3 Rejected (error) Outgoing Transfer
7 Accepted (processed) Outgoing
Transfer (no accounting entry)
N Incoming Funds Transfer
"P" =Possible Duplicate
44
NUM
EBCDIC data representation standard;
includes any numeric digit0-9.
OBI=
Field tagused toidentifyOriginator to
BeneficiaryInformation inthe current format;
information conveyed from the originatorto
the beneficiary.
Field tagused toidentifyOriginator’sBank in
the currentformat; the bank actingforthe
originatorofthe transfer.
OGB =
OMAD TAG [1120]
Field used tocarry the Output Message
Accountability Data. OMAD isestablished at
the time the message isqueued fordeliveryby
a Federal Reserve Bank; includes the date,
the logicalterminal (Lterm) associated with
the interfacingapplication thatwillreceive the
message from Fedwire, a sequence number, a
time stamp, and a code identifyingthe FRB
deliveringthe message.
ORG =
Field tagused to identifythe Originator inthe
current format; initiatorofthe transfer.
45
ORIGINATOR1
The sender ofthe firstpayment order ina
funds transfer. Also see TRANSMllTOR.
ORIGINATOR’S BANK1
The receivingbank towhich the payment
order ofthe originatorisissued ifthe
originatorisnot a bank, or the originatorif
the originatorisa bank. Also see
TRANSMITTOR’S FINANCIAL
INSTITUTION.
ORIGINATOR TAG [5000]
Field used toidentifythe sender ofthe first
ORIGINATOR’S FINANCIAL payment order ina funds transfer.
INSTITUTION TAG [5100]
Field used toidentifythe bank or non-bank
financial institutiontowhich the payment
order ofthe originator isissued.
OUTGOING FUNDS
TRANSFER
A payment order sent from a participating
financialinstitution,the sender, tothe
Fedwire application. Ifaccepted by Fedwire,
the sender’saccount isdebited and the
receivingFI’saccount iscredited, and a
corresponding outgoing funds transferis
delivered tothe receiving FI. See
INCOMING FUNDS TRANSFER.
OUTGOING TRANSFER
RESPONSE
See INTERCEPT.
46
PAYMENT ORDER1
An instructionofa sender to a receivingbank,
transmitted orally,electronically,or inwriting,
topay, or to cause to another bank topay, a
fixedor determinable amount ofmoney toa
beneficiaryif: (1)the instructiondoes not
statea condition ofpayment tothe
beneficiaryother than time ofpayment; (2)
the receivingbank istobe reimbursed by
debitingan account of,or otherwise receiving
payment from, the sender; and (3) the
instructionistransmitted by the sender
directlytothe receivingbank or toan agent,
funds transfersystem, or communication
system fortransmittalto the receivingbank.
Also see TRANSMITTAL ORDER.
PREVIOUS MESSAGE
IMAD TAG [3500]
Field used toreference the IMAD ofan
earlierfunds transferwhen the sender is
returning, correctingor otherwise referencing
a transferpreviously sent or received.
RECEIVING BANK1
The bank towhich the sender’sinstructionis
addressed.
RECEIVER DFI NUMBER
TAG [3400]
Field used tocarrythe nine-digitrouting
number and short name ofthe receiver.
RECEIVING FINANCIAL
INSTITUTION1
The financial institutiontowhich a sender’s
instructionisaddressed. The term "receiving
financial institution"includes a receivingbank.
47
RECIPIENT1
The person tobe paid by the recipient’s
financialinstitution. The term recipient
includes a beneficiary.
RECIPIENTS FINANCIAL
INSTITUTION1
The financialinstitutionidentifiedina
transmittal order inwhich an account ofthe
recipientistobe credited pursuant tothe
transmittalorder orwhich otherwise isto
make payment tothe recipientifthe order
does notprovide forpayment toan account.
The term recipient’sfinancialinstitution
includesa beneficiary’sbank.
REFERENCE FOR THE
BENEFICIARY TAG [3321]
Field used toprovide reference information
thatenables the beneficiary toidentifythe
transfer;the beneficiaryreference element
may containup to 16 characters (letters
and/or numbers).
RFB =
Field tagused toidentifythe Reference for
the Beneficiary inthe current format, see
REFERENCE FOR BENEFICIARY TAG
[3321].
SENDER1
The person givingthe instructionto the
receivingbank or receivingfinancial
institution.
SENDER FI NUMBER TAG
[3100]
Field used tocarrythe nine-digitrouting
number and short name ofthe sender.
SENDER REFERENCE TAG
[3320]
Field used tocarrythe sender’sreference
number; may containup to 16 characters
(lettersand/or numbers).
48
SENDER SUPPLIED
INFORMATION TAG [1500]
Field isused onlyforoutgoing and
intercepted funds transfersand contains three
elements: user request correlationdata,
test/production code, and message duplication
code (in). The elements are described below:
User Request Correlation Data: May be used
toidentifyan inquiryrequest and the
requesting terminal ina multi-terminal
environment. Fedwire returns the contents of
the originaloutgoing message when sending
an interceptmessage.
Test/Production Code: See description under
MESSAGE DISPOSITION TAG [1100].
Message Duplication Code (In): See
descriptionunder MESSAGE DISPOSITION
TAG [1100];modified as follows.Values are:
"" Original Message
P
Possible Duplicate
SPECIAL HANDLING
INSTRUCTIONS TAG [1140]
Field isused by Fedwire toinsertspecial
handling instructions.
49
TAG
Used todenote the beginning ofa field. In
the proposed format, a tag iscomposed ofsix
characters inthe form [nnnn],where "n"isa
number, the leftbracket"["isthe first
character, and the rightbracket"]"denotes
the end ofthe tag. There are thirty-threetags
defined. Also known as a "fieldtag".
In the current format, a "fieldtag"denotes the
beginning ofthird-partyinformation, and is
composed offour characters inthe form
aaa=, where "a"isa letterand equals sign
denotes the end ofthe tag. There are nine
tags: ORG=, OGB =,IBK=,BBK=, BNF =,
RFB=, OBI=, BBI=,and INS=.
TRANSMITTAL ORDER1
An instructionofa sender toa receiving
financial institution,transmitted orally,
electronically,or inwriting, topay, or tocause
topay, a fixed or determinable amount of
money to the recipient if:(1) the instruction
does not statea condition topayment to the
recipientother than time ofpayment; (2)
receivingfinancialinstitutionistobe
reimbursed by debiting an account of,or
otherwise receivingpayment from, the sender;
and (3) the instructionistransmitted by the
sender directlyto the receivingfinancial
institutionor toan agent or communication
system fortransmittal tothe receiving
financial institution. The term transmittal
order includes a payment order.
50
TRANSMITTOR1
The sender ofthe firsttransmittal order ina
transmittal offunds. The term transmitter
includes the originator.
TRANSMITTOR’S
FINANCIAL INSTITUTION1
The receivingfinancialinstitutiontowhich the
transmittal order ofthe transmittorisissued if
the transmittorisnot a financialinstitution,or
the transmittorifthe transmittorisa financial
institution. The term transmitter’sfinancial
institutionincludesthe originator’sbank.
TYPE/SUBTYPE CODE TAG Field indicatesthe transfertype and sub-type.
[1510]
Type Code Values:
10 Third-party Funds Transfer
15 Foreign Transfers --Foreign
Central Banks and International
agencies
16 Settlement Transfers
Sub-type Code Values:
00 Transfer
01 Request forReversal
02 Reversal ofTransfer
07 Request forReversal ofPrior
Day Transfer
08 Reversal ofPriorDay Transfer
20 "As-of"Adjustment
31 Request forCredit (Drawdown)
Transfer
32 Funds Transfer Honoring a
Request forCredit (Drawdown)
Transfer
33 Refusal toHonor a Request for
Credit (Drawdown) Transfer
90 Service Message
-51 Appendix A
FORMAT PROPOSAL
ListofTags by Message Type
B
Tag
Description*
A
Tag
Number
noned
[1100]d
[1110]d
I [1120]d
[1130]d
[1140]d
[1500]d
[1510]d
[1520]d
[2000]
[3000]
[3100]
[3320]
[3321]
[3400]
[3500]
[3600]
[3700]
Interface Code
Message Disposition
Acceptance Timestamp
OMAD
Error Field
Special Handling
Instructions
Sender Supplied
Information
Type / Subtype Code
IMAD
Amount
Adjustment
Sender DFI
Sender Reference
Reference forBeneficiary
Receiver DFI
Previous Message IMAD
Business Function
Chargesf
E
Intercept
Response
To
Outgoing
Transfer
C
Max.
Field
Size
D
Outgoing
Funds
Transfer
(with
Tag)b
(DFI to (Fedwire to (Fedwire to
DFI)
Fedwire)
DFI)
Order inwhich fieldappears in
message.
1
9
18
36
46
33
01
18e
02
05
10
24
24
14
34
23
23
34
03
04
05
06
07
08
09
10
11
12
13
06
07
08
09
10
11
12
13
14
24
9
9
01
02
03
04
15
16
F
Incoming
Funds
Transfer
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
-
52
-
Appendix A
FORMAT PROPOSAL
ListofTags by Message Type
1 TagA
Number
[4000]
[4100]
[4200]
[5000]
[5100]
[5200]
[6000]
[6100]
[6200]
[6210]
[6300]
[6310]
[6320]
B
Tag
Description*
Intermediary FI
Beneficiary’sFI
Beneficiary
Originator
Originator’sFI
InstructingFI
Originator toBeneficiary
Information
FI to FI
Receive FI Information
FI toFI
Intermediary FI Information
FI toFI Advice Information
FI toFI
Beneficiary’sFI
Information
FI toFI
Beneficiary’sFI
Advice Information
FI to FI
Beneficiary Method of
Payment
E
Intercept
Response
To
Outgoing
Transfer
C
Max.
Field
Size
D
Outgoing
Funds
Transfer
(with
Tag)b
(DFIto (Fedwire to (Fedwire to
DFI)
DFI)
Fedwire)
Order inwhich fieldappears in
message.6
14
17
16
15
18
17
16
19
18
17
20
19
21
18
20
22
19
21
22
20
23
186
186
191
186
186
186
150
222
(Total
forall
tagsin
[6100] to
[6500]
series)
F
Incoming
Funds
Transfer
21
24
23
22
25
24
23
24
26
27
25
26
25
28
27
26
29
28
-
53-
Appendix A
FORMAT PROPOSAL
ListofTags by Message Type
B
Tag
Description*
A
Tag
Number
[6400]
[6410]
[6500]
FI toFI
Beneficiary Information
FI toFI
Beneficiary Advice Information
FI to FI Information
E
Intercept
Response
To
Outgoing
Transfer
C
Max.
Field
Size
D
Outgoing
Funds
Transfer
(with
Tag)b
(DFI to (Fedwire to (Fedwire to
DFI)
Fedwire)
DFI)
Order inwhich fieldappears in
message.'
F
Incoming
Funds
Transfer
21
30
29
28
31
30
29
32
31
descriptionofthe currentformat isinthe Computer InterfaceProtocol Specifications (CIPS) pages 5.8.1,
>,and 5.8.9.
l
Charactercount includes sixcharacter tagconsistingof4 digitsand 2 brackets.
►ptional tags may be omitted from message. A blank indicates the tag isnot used in this message type,
dmum message size has also increased: Outgoing has 604 characters in the current format, 1731 in the
>osedformat; Intercept 731 current, 1834 proposed; and Incoming 723 current, 1808 proposed.
he interfacecode and fieldswith tags inthe 1000 seriesare designed tocarry technical information. The
ents and purpose ofthese tags and fieldswillbe more fullydefined when the CIPS are published.
ieldwillcontain 16 characters inan intercept message because format code isomitted.
eldisreserved forpossible future use.
@FedFRASER